Security static code analysis is performed together with other static code analysis methods at or before compilation time. The biggest advantage of using static code analysis tools is that they can be used in the very early stages of the projects, long before the code has reached a state where it can be executed and evaluated with traditional quality assurance methods. With the high level of automation that can be achieved, static code analysis is an ideal tool to introduce a minimum code quality level without wasting the precious time of security experts on routine manual reviews. Common automation options in particular include automated execution of code auditing at check-in to SCM, as well as automated failing of a build in centralized build environments (e.g. when using CI systems such as Jenkins).

Static code analysis tools cover a broad range of code analytics options, ranging from trivial pattern matching tools to find comments in the code like “todo” or “fixme”, up to very complex execution path analysis tools. Such advanced tools can observe, for example, a specific variable through the execution path of a method and make deductions on the reliability and sanitation status of data stored in such variables.

Depending on the policies of the organizations and products, any form of static code analysis may be security relevant. While it is common understanding that execution path analysis often provides valuable insights on security, some organizations may decide that enforcing specific code formatting is relevant to their security program. One justifications for this is that a common definition of whitespace across the project’s developer community makes semi-automated code reviews easier.

For these reasons, static code analysis is mostly policy driven, and the (secure) coding policies that an organization defines ultimately drives the selection of tools and their configuration. Consequently, the selection of approved tools and their (project specific) configuration is key in making static code analysis a significant contributing factor to application security. As with any policy, the static code analysis rule set, as well as the list of approved tools need periodic reviews to make sure that the latest advances in security research and subsequent tool improvements are incorporated into a project’s security strategy.

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.

The processes I described earlier for security requirements analysis and architecture threat analysis earlier seem very heavy weight, and a question that I get asked frequently is how to use such processes in agile models. At this time, HP is the third largest software company in the world (measured in total software revenue, behind IBM and Microsoft). There is a huge bandwidth of software development models in HP: I have been leading secure software development lifecycle (SSDLC) programs in both HP Software and HP’s Printing and Personal Systems group, working with teams that employed traditional models (“waterfall style”) as well as with teams that used more progressive models (Scrum, XP, SAFe, etc).

With all teams I worked with, it was possible to create an SSDLC program that accommodated the individual team’s working model. As an example, while a team using a traditional waterfall model will perform the requirements and the design analysis in their “planning stage”, an agile team will commonly have already completed these activities in their previous Potentially Shippable Increment (PSI). In other words, while the majority of developers in a team that uses e.g. SAFe may be working on PSI n, part of the team has already started work on the analysis of the requirements and design that will go into PSI n+1.

The steps that need to be performed in a secure development lifecycle program are independent of the development model, but how they are scheduled and executed may be different with every organization. It is important to design the SSDLC program to match a team’s needs, and it is equally important to create metrics for the SSDLC program to match an organization – making sure that the metrics reflect not only the aspects of the SSDLC program, but also fit into the existing model of how an organization is measured.

Deadlines and budgets in software projects are usually tight, and managers often ask me which would be more beneficial for them to meet their goals: Security requirements analysis or architecture threat analysis?

Asking this question is comparing apples to oranges, as these are two different things and both of them provide substantial benefits. The security requirements analysis helps to ask the best questions to get the requirements right. Getting requirements wrong is a common issue, in particular when complex regulations are involved (which is frequently the case with security requirements). Without proper requirements analysis, the product team may end up doing the greatest job of building the wrong thing.

Architecture threat analysis ensures that the product is designed to be robust and resilient from a security perspective. If this step is omitted, the application may be riddled with security vulnerabilities – and hence not meet basic security requirements either.

The security requirements analysis ensures that the team is building the right product from a security perspective, and architecture threat analysis makes sure that they are building the product right.

Once all requirements for a project have been gathered, it commonly enters the “design” phase of the development lifecycle. In this phase, the architect(s) turn the prioritized requirements into an application blueprint for coding. This is a crucial phase during software development, as some decisions made here are irreversible once implementation has started (or, at least, very hard to change without significant investments).

During this phase, the security architect starts analyzing the overall attack surface of the design. This analysis is ideally performed on the design specifications created by the other product architects, before any code is written. The assumption is that the implementation of any software component may be flawed, and the goal is to reduce the opportunities for attackers to exploit a potential vulnerability resulting from such a potential flaw. During this step, the design may change by removing or restructuring specific components, and additional (run-time) requirements that mitigate or reduce specific risks resulting from the design may be introduced. An example for design changes may include layered defenses, while additional requirements may include restricting access to specific services and determining the level of privilege required during execution.

Common approaches to threat analysis include attack surface analysis as well as quantitative and qualitative risk analysis. Unfortunately, skilled security architects who can perform an in-depth threat analysis are rare, which usually makes this particular step the most expensive part of a secure development lifecycle program. The key to success is using the available resources wisely, and creating a repeatable and scaled approach that consistently produces high-quality results.

There are several (more or less) structured brain-storm-based approaches for threat analysis. The more structured ones commonly have some level of tool support (e.g. “threat model tools”) which helps to make the process somewhat more comprehensive, while the less structured ones depend fully on the participants’ creativity and security expertise. The inevitable variability in these factors as well as in the participants’ stamina can produce dramatically different results.

Applying a maximally structured approach to threat analysis commonly allows identifying architectural security risks more consistently, more effectively, more repeatable, and at a significantly lower cost. It also allows determining both the risks from the identified threats, and establishing appropriate mitigations. Most importantly, it also achieves completeness that a brainstorm-based approach commonly cannot guarantee: when employing a structured approach, the security architect can utilize measureable criteria to determine when the threat analysis is complete, and not simply because they “cannot think of any more problems to look at.”

Threat modeling is, for the most part, ad hoc. You think about the threats until you can’t think of any more, then you stop. And then you’re annoyed and surprised when some attacker thinks of an attack you didn’t. – Bruce Schneier

Once the main epics of a product release are known, the team can get into a more detailed “what needs to be built” analysis, and even get a first high-level understanding of the “how”.

The majority of the main functional and non-functional requirements can be derived from the product vision. During the requirements analysis, this initial set of requirements becomes more detailed and the architects start adding more comprehensive requirements that are, for instance, derived from best practices. In this step, the Security Architect will start a security requirements analysis to add to the requirements pool for the project. Eventually, this pool will translate into user stories and tasks and be assigned to PSIs (when following an agile development model like SAFe), but we are not quite there yet!

The security requirements analysis usually starts with an analysis of the product’s target market. As an example, if the product is meant to be sold to medical offices in the US or meant to process credit card payments, a lot of mandatory requirements derived from HIPAA and PCI respectively must be implemented by the product, or it cannot be shipped. On the other hand, if the product is mostly used by consumers, there are a lot of best practices that drive requirements for the product, but many of them are not mandatory for the product to be released.

Once the target market has been determined, the Security Architect should reach out once more to product management and marketing to understand if there are specific features that would allow the product to perform better in the market. Commonly, the Security Architect will help marketing and product management to analyze products of competitors, and suggest improvements that would distinguish the product from the competition. Trivial examples include offering encryption or privacy protection where competing products transfer or store data in plain text, implementing strong auditing and giving the customer easy access to such data, and offering secure and innovative authentication mechanisms where competitors only support username / password based authentication.

Security requirements are often derived from laws and regulations which are often far outside the comfort zone and experience of most developers and product architects. Security stakeholders on the customer side are business information security managers and chief information security officers (CIOs) who speak a language of their own, often leading to misinterpretation of the provided non-functional requirements by the product team. A Security Architect performing the security requirements analysis understands both the relevant legal regulations as well as the language used to correctly interpret them, and translates them into a language commonly understood by product development teams to ensure regulatory compliance.

After these preparatory steps have been completed, the Security Architect commonly works with the product architect(s) on a weighted and prioritized requirements list that ties back to the original target market analysis and also shows the inter-requirements dependencies. This requirements list is meant to help product management decide which security feature to implement for a specific release. It is a decision tool that allows product management to understand that if they want to sell the product to a specific market segment, or sell the product in a specific country, the product has to implement specific requirements. Also, the list might have some “non-negotiable” requirements, which must be implemented e.g. to satisfy corporate security policies.

Highlighting requirements inter-dependencies helps with coarse-grained effort estimations. As an example, if requirements X, Y, and Z depend on a complex set of requirements A, B, and C, and X, Y, and Z are required to sell in a specific market, then product management might decide to delay this feature set for a release or two to allow some extra implementation time to implement A, B, and C first, and rather focus e.g. on a different country in the first release.

At the end of the requirements analysis, the product team should have a clear understanding of what needs to be built to address both short-term and long-term security and privacy concerns for the specific target markets, as well as which requirements to implement first, and options of how to implement them so that they can start the product small and grow it long-term, without painting themselves into a corner.

For the majority of software products, security is primarily a cost factor. Regular readers of my blog keep asking me how they should afford all these expensive and time-intensive security counter measures like code reviews, code analysis, and pen testing.

It is interesting to see that the majority of security related costs in many products still accumulate at the end of the development lifecycle. The closer a product gets to its scheduled release date, the more investments in security are being made. I frequently still see a “test security in” approach in products that quickly evolve in the beginning without considering security, while there are few product teams that try to get the security related parts of the product right in the first place to avoid the high costs of extensive late-stage security counter measures and, in the worst case, major design changes in a late development stage.

Security vulnerability aggregators like the NVD and the underlying security vulnerability databases list around 60 thousand different publicly known vulnerabilities. There are indications from research performed by IBM that the number of actual security vulnerabilities that are not publicly known could higher by a factor of 20, which indicates well over a million open or latent security vulnerabilities in major products that are tracked in the NVD.

The cost of fixing a defect at various stages of the development lifecycle grows exponentially from the requirements stage over design, coding, testing, and maintenance. This observation lead to the undisputed statement that attempts to test quality into a product are generally futile, at least when cost is a factor to be considered. As security is one aspect of software quality, the statement also holds for the unfeasibility to test security into a product. Yet, the pen testing tool and consulting industry is booming, and while many software vendors use security testing tools and pen testing, few are using security requirements and design analysis early enough in the product lifecycle to prevent security issues in the first place and avoid the horrid costs of fixing security defects after the product has been released.

To change a product team’s Secure Software Development Lifecycle (SSDL) approach and ensure acceptance, it is important to meet a product team where they are, and not try to force new development models on them when they are not yet ready for a major change. When working with product teams, I generally try to establish a more proactive model than what the team is using, presenting various options and recommendations, and then work with the team leads to find out what works best for them.

Typically the best solution is to use all of these approaches as needed in a closed-loop SSDLC program, investing most of the available resources in the proactive counter measures, then in the automatable counter measures, and least in the manual and most reactive counter measures.