This is the 38th blog in a series about security and how security is about how you think.
In the last blog, I started to discuss the concept of a “software development lifecycle” (SDL) and how it helps produce great software that doesn’t fail. But is that software secure? How do we know?
Let’s draw an analogy to building a house. A construction company starts with designs of what the final product will look like and then starts to build. At many times throughout the construction process, independent assessments (code inspections in the United States) are done either by the local government or a trusted third party. These assessments make sure that the work is done correctly, and there won’t be any problems later in the construction. Inspections are done for the framing, electrical, plumbing, roofing, etc. If issues are found, they are fixed before the next step occurs. When the house is done, it should be well constructed. If the house is being sold, another “home inspection” is usually scheduled to uncover any problems that have happened since the house was built (as the house is being used). In all, these inspections examine the house to ensure that it is structurally sound and secure.
The same process happens for software development. Gartner defines Static Application Security Testing (SAST) as a “set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the “inside out” in a non-running state.” (https://www.gartner.com/it-glossary/static-application-security-testing-sast). So, SAST tools are the code inspectors (literally) to ensure that the code that is being written is good and doesn’t suffer from common bad programming mistakes. Each language should have a static analyzer that knows what in that language can contribute to bad code – for example, a buffer overrun.
But it doesn’t just check for bad programming. Most SAST tools also compile metrics (statistics) about the code to show how complicated it is. Take this analogy to our house – a simple shed is very easy to get right – you just put up the walls, bolt them together, attach the prefab roof, put on a little paint and it’s ready to go. If I want to build a few, they’re all going to be exactly what I would expect, since it’s very close to the original (and simple design). But then compare that to a huge mansion with extensive custom carpentry and other unique features. Not that easy to get right, because it’s not a standard design. Code complexity metrics help understand where the current project falls. The metrics around code complexity help the project owner understand if code is fairly straightforward (easy to get right) or complicated (hard to get right) and where to invest more effort.
SAST tools are just a few of the tools in the DevSecOps toolbox. They are the programs that help the developers write better programs and catch the edge cases and inadvertent programming mistakes that happen during code development. They assist the project owner, architect and developer to be better and to THINK security when they use them. How and when they use these tools is also important. Running the tool once right before the code is put into production is a good first step, and will probably catch a few errors, but running the tools for every build would be better. Running the tools in an automated environment where the coders just get the reports on what they’ve done is even better. In any case, it’s the way that you THINK about the security of the code that is most important here.