Once a solid approach to architecture threat analysis has been established, most of the remaining security vulnerabilities are coding problems, that is, poor implementation. Examples include injection issues, encoding issues, and other problems such as listed at the OWASP Top 10 Project.

While a checklist of best practices for developers can help with addressing some of these bad coding habits, a more structured and repeatable approach should be established as well. Static application security testing (or “Static Code Analysis” – SCA) can identify most of the code-level vulnerabilities that remain after a thorough architecture threat analysis. However, it is crucial that SCA is executed consistently and automatically.

A common best practices is to analyze any newly written source code prior to compilation or, for scripting languages, prior to promoting it for an intermediate release. Automating this process in a build system / continuous delivery tool chain makes this very scalable and can also ensure that developers follow specific secure coding best practices.

When implementing automated SCA during builds, the project owner needs to make a decision of whether to fail a product build if the SCA process fails. I generally recommend that a developer should be able to run the entire toolchain on their local machine. This allows them to run the entire build locally, as it would be executed on the central build server, with all checks and automated tests, before they commit to source control. This does not only ensure proper execution of security tests, but also other quality assurance tools such as regression testing.

The Hat of Shame (https://www.flickr.com/photos/foca/6935569551)

However, to improve their productivity, the developers must have the option to skip tests locally. To avoid developers committing bad code to source control, and so trigger unnecessary builds on the central build server, they must also have the option to configure the same tools that are used in the build chain for use in their IDE – with the same rules as used in the central project configuration, so that they can execute the SCA while they are writing the code, and justify skipping the SCA build locally before checking in.

Using such a setup ensures that developers can deliver code that meets the individual project’s standards. I generally also recommend failing the build on the central integration build server if committed code does not meet these standards. In most cases, this is caused by a developer not using the toolchain (including the local tools for the IDE) as instructed and so causing unnecessary work and delays for the rest of the team – which means that this developer is entitled to wearing the hat of shame for a while.