Most people involved in the process of creating and deploying software applications today are familiar with DevSecOps, which integrates security and operations into the software development process. In figurative terms, we think of the software development lifecycle as a timeline, starting with the design on the left and the deployment (and post-deployment activities) on the right.
Historically, security was overlooked until as late as possible in the process; it was something to consider once you had a viable product. But the truth is, ignoring security early on makes it harder and more costly to add on later.
As DevSecOps continuously pushes security “to the left” in the software development process, autonomous assessment can provide assurance of security compliance from development’s earliest stages. One type of autonomous assessment, static application security testing (SAST), can help identify software flaws early on.
Let’s explore how using SAST helps DevSecOps achieve its stated goals while minimizing friction.
What SAST offers
Experienced software developers can integrate correctness, robustness, efficiency, elegance and even security into the code they create. However, even the best developers don’t get it right every time. And less experienced developers tend to deviate from standards and best practices in order to get the job done. In today’s push to deliver products quickly and efficiently, it gets harder and harder to pay attention to all the details, including security.
SAST can provide a valuable tool in the software developer’s toolbox for writing quality code. Far from some initial developers’ perception, SAST isn’t just one more hoop to jump through. Strategically laced SAST assessments can alert developers and management that potential flaws exist and should be addressed early in the process.
Developers commonly find that SAST helps them to be more efficient. The last thing you want to find is a critical design flaw that stays hidden until the final testing before release. SAST can increase the likelihood you’ll find flaws long before they get “baked in.”
One great way to leverage SAST’s value is to require assessment of all code before the initial check-in. You don’t (or shouldn’t) ever commit code that doesn’t compile, so why should you be able to commit code with security flaws? Find the flaws and fix them before committing work to the pipeline.
Instead of increasing each developer’s workload, you’ll decrease (in many cases dramatically) the time required down the road in rework to fix flaws someone else finds. Plus, complete SAST codebase scans may take hours. Individual and small-batch scanning is much faster. Requiring developers to carry out SAST scans locally distributes the overall workload and reduces friction along the development pipeline.
Although giving individual developers the ability to automatically flag potential issues is a huge benefit, management and auditors enjoy SAST’s help in doing their jobs as well. Developers can fix flagged issues before committing code, but some errors won’t be found until more comprehensive tests, including integration tests, get carried out. For example, pre-build SAST assessments may identify flaws that unit-based SAST assessments couldn’t see.
Each time SAST identifies new flaws, management has the opportunity to assign mitigation resources to fix the flaws before the code moves ahead in the pipeline. While consuming resources to fix flaws may seem inefficient, experience shows that fixing flaws early in the process is always cheaper and faster than finding the flaw later and having to fix it then.
Obstacles to using SAST effectively
SAST may seem to be a magic solution for finding security flaws but while SAST can provide impressive benefits, the benefits aren’t free.
Most SAST toolsets, such as Kiuwan’s Code Security (SAST), work well in general environments right out of the box. However, no product works perfectly for any specific environment. Your code is different from anyone else’s code. Although coding standards go a long way toward aligning the structure and “tone” of code your organization creates, there will always be nuanced differences between individual developers, and certainly between different development organizations.
You’ll probably find that the first time you run a SAST tool against your code base, you’ll get a very high number of alerts. In most cases, a non-trivial number of these are false positives. False positive results mean that the SAST tool identified a potential flaw that is not an actual flaw, and your rulesets are too restrictive. You’ll need to customize the rulesets your SAST tool uses to assess source code. The goal should be to reduce false positives to a minimum, while not becoming so lenient as to miss important flaws.
Until you tune your rulesets to minimize the results you receive, many new SAST tool users find it confusing to prioritize mitigation responses. With many potential flaws, how do you determine which ones should get resources? While there is no “best” answer, a well-balanced approach is to initially explore any flaws that are related to mission-critical functions, and then use your SAST tool’s criticality rating to focus on the most critical. As you fine-tune your rulesets, you’ll have fewer potential flaws to examine. Of course, document any false positives you find to help drive ruleset tweaks to exclude those in future scans.
One additional obstacle to using SAST may come from management. Although it is likely that management provided the initial motivation to integrate SAST, the large set of results from early SAST scans may lead management to believe that the codebase is full of flaws. Before implementing SAST, set expectations of all stakeholders. The initial SAST scan does not, in most cases, indicate how bad your code really is; it provides starting points for ruleset modifications and security flaw mitigation actions. Ongoing management support is crucial, from SAST implementation through enjoying the full range of benefits automated security testing can deliver.
Best practices for integrating SAST
If you’re interested in implementing SAST in your DevSecOps environment, how should you start? (By the way, you don’t have to be a DevSecOps or agile shop to use SAST. SAST just fits into DevSecOps and agile environments rather nicely.) Follow these best practices to get the most benefit from SAST.
Identify a SAST product
The best place to start is to identify your SAST product of choice. There are many products out there, and you’ll learn a lot by comparing several products to determine which features would fit into your environment best. One neutral source of information is the OWASP Source Code Analysis Tools page. This list may seem long, but it’s a great start.
Define scan scope and milestone triggers
You don’t want to conduct comprehensive SAST scans every time you use the tools. Scanning too much wastes time and duplicates effort. The key to efficiency is to identify the right scan scope for appropriate pipeline milestones.
You’ll probably want to launch SAST scans for at least these milestones:
- Pre-commit (before check-in): Scan the object, and perhaps immediately related objects, before committing them to the code repository.
- Commit (check-in or task complete): Scan all code objects directly related to a task or project as a process of committing the code to the code repository. This step may seem redundant with a pre-commit scan, but the scope will generally be a little larger here.
- Build: Part of your build process should be a SAST scan.
- Test: Since SAST is a type of testing, it should be in the formal test suite that gets exercised during formal testing.
- Deployment: Perform one last SAST sweep to ensure nothing got through earlier iterations.
Ensure you have full team support
Since SAST does add to the workflow effort, you must maintain support from all members of the team, including management. The early implementation phases of any new toolset commonly require an adjustment period. Full team support can make that period of time less contentious.
Understand what results mean
Every alert doesn’t equate to bad code or a true security flaw. Results are only indicators of potential issues. Use your SAST results to customize your testing rulesets, find true flaws, and identify trends that could influence coding standards changes.
Operationalize progressive elaboration
Don’t pretend to know everything about SAST or your codebase up front. Chances are that you’ll learn a lot about both as you begin to use your new toolset.
Finally, if you want to look at a case study and discussion of how SAST could be used, check out the customer success story.
Take a look at integrating SAST into your development pipeline. When you see how SAST helps accomplish your DevSecOps goals, you’ll be glad that you did.
