Secure Development Process

We specify any new feature in our engineering tracking systems, which is visible to everyone involved in the development process. A new feature is written as a “User Story.” A “User Story”  describes what a specific end-user might need to do, and the end-user of the feature might be someone other than a user connecting to the application; it could be an internal operations person or a client’s security team who might have specific requirements or wishes.

Part of each user story is acceptance criteria, which need to be fulfilled before delivering a feature. At this point, we are considering security implications, and we need to go beyond the standard requirements. Those security requirements can come from a wide range of sources, such as attack vector analysis, lessons learned from previous features, internal or external commitments, or industry best practices.

In case of complicated, risky, or significant features, we might first investigate or conduct a “spike” to determine added risks, optional solutions, or other items that are not clear during a story definition stage. The investigation could be something like evaluating third-party solutions we could incorporate or new technical frameworks we might want to use. Especially around sophisticated features, we also perform an architecture design first to ensure that we consider not only the function itself but also the implications on operations, security, or existing or other planned elements in the solution.

We schedule development only once a story is well defined and agreed upon. We follow a set of coding standards like a style guide, security areas such as the OWASP Top 10 to keep in mind, licenses that are acceptable if we are using external sources, etc. The set of standards are documented in our internal knowledge base.

Coding of a feature is done in a branch of our source control that is outside the main, production branch. Only when coding is complete, and several stage gates have been passed, a complete, releasable feature is merged into the production branch and will become part of the next release.

Those stage gates include:

• A code review has been done by someone other than the coder(s)
• The code builds without errors or problems
• Builds still pass all unit, User Interface, and API tests that passed before the code is merged. Across the platform, over 50,000 automated tests are run and checked for each release
• Unit tests have been created for this feature and pass
• Integration tests pass
• Our QA team has confirmed that all Acceptance Criteria listed in the User Story are met
• A static code analysis passes without significant issues
• A vulnerability scan for known vulnerabilities in third-party components passes without significant issues

Once a feature is complete and approved, we organized a final hand-off meeting. The meeting includes the feature developers, our DevOps team, and our Product Manager to address upgrade/update/rollout and other operational concerns. At that meeting, we give the final approval to release the new functionality.