Yellow Dog Software Development follows a series of policies and procedures to ensure that products developed by Yellow Dog Software are stable, secure, and reliable for intended customer use. While it is not our policy to share specific details of coding practices that we use to protect against security vulnerabilities, this document includes high level details on our policies regarding the development of our products. Code reviews are done as part of our standard process to ensure coding guidelines are followed and to ensure a high quality of code.

These guidelines include, but are not limited to, the following:

  • Never use client input directly to execute a statement or allow for generation of a dynamic SQL statement. Input provided by the client should only be used as raw data in specific elements and never as executable code. Our product is SQL based, and dynamic queries are used in various ways, but all user input and anything embedded in SQL is sanitized to prevent SQL injection attacks.

  • When working with files from an application, avoid use of parameters for filenames and check security resources before manipulating files.

  • Assuming that adversaries could have our source code, never store anything directly in source code that could be useful in an attack, such as a cryptographic key or password.

  • Never check prototype or demo code into main source trees or branches accessible to main source trees. Prototype code may not yet have had a full security review and demo code may skip some (security-related) best practices in the interest of highlighting a particular feature or function.

  • Avoid use of public variables and ensure all variables are scoped within appropriate procedure blocks to prevent external manipulation of variables.

  • Do not allow external APIs to ask the server to execute specific methods by use of parameters.

  • Avoid URL parameter vulnerabilities (the series of mechanisms to avoid are not outlined in this document for security reasons)

  • Keep sensitive data in memory for ONLY as long as needed and clear caches as appropriate.

  • When submitting a code change, include testing instructions for our quality team that describe how to attempt to provoke a Denial of Access if this area allows for user invokable code and state the level of user access required.

  • Utilize cryptography appropriately (guidelines not included in this document for security reasons) and utilize the standard cryptographic algorithms provided in our system APIs.

  • Ensure all web services are secured and encrypt the username tokens.

  • Clearly document the roles that an API or feature requires in order to minimize the chance that site developers and administrators over-privilege roles due to lack of understanding of discrete resource needs.