The term DevSecOps is a contraction of DevOps, itself a contraction of Developer Operations, and Security. It’s the in-vogue buzzword for 2018 that, despite the hype, does have positive implications for improving application security. Many organizations have adopted DevOps over the past years and integrated their continuous integration and deployment processes. However, in many cases, security has been left out of this integrated pipeline. In DevSecOps companies are aiming to put security as a first class contributor into the everyday processes and equal alongside development and operations.
This post takes a look at the role of static application security tools (SAST) such as GrammaTech CodeSonar and how they can be used in Dev(Sec)Ops and continuous development pipelines to improve quality and security.
DevOps and Security
DevOps applications don’t intentionally leave out security but like any other development method, unless it’s part of the requirements and development culture, it doesn’t get done. Which leads software teams to either ignore security or delegating it it to the end of the development effort, which means that people try to ‘tack on’ security at the end. And as any security practitioner will say, “security needs to be built in from the beginning, not added at the late stages of product development.” Or in other words, “pay me now, or much more later.”
In addition, a key reason to build security into agile and continuous processes is to build upon the knowledge that accumulates over the project. It’s not reasonable to expect software teams to understand their complete attack surface, for example, at the beginning of the project. Building security into day-to-day operations accumulates expertise and knowledge. Starting early is the key. With that in mind, DevSecOps is often illustrated as follows on the DevOps flowchart – security in every part of cycle:
Source: “Tripwire – Security at the Speed of DevOps”
Security as Code
An interesting approach that has come out of DevSecOps research and practice is the concept of treating security in the same ways as code is; it is guided by requirements, which leads to implementation of security controls, then to validation through testing, and of course requires documentation. It’s one of the key ways to integrate security into DevOps and a good way to build security into the development culture and have software teams communicate using familiar language. Certainly, security implementations that end up as actual code with associated tests can be automated in the same fashion as other code. Automation tools apply here as would any tool that works with requirements, tests, documentation, etc.
Role of SAST in DevSecOps
Static analysis tools (SAST) integrate well with just about any software automation tool chain and development methodology and process. This is mainly due to the fact they can be used locally by developers at their desktop for instantaneous feedback and used to analyze a complete build whether that’s done hourly, or whenever. In addition, SAST tools are completely autonomous since they require no interaction with testers or developers. They are applicable whenever it makes sense to check for bugs and security vulnerabilities in the code:
- Coding: This is the critical time to detect any new security vulnerabilities, as soon as developers write new code even before it’s submitted to a build or software control system. CodeSonar, for example, presents these vulnerabilities immediately in the developer’s IDE just like a compiler warning, providing easy and actionable corrective action (such as vulnerability assessment, root causes and control and data flow traces.)
- Building: Analyzing an entire project provides SAST the complete scope of the application to analyze and detect complex vulnerabilities. For example, tainted data analysis can detect SQL and code injection vulnerabilities that result from non-existent validation of user and system input.
- Testing: Any code changes done during testing need to be revaluated with SAST to prevent new vulnerabilities being introduced. SAST tools should also be used to evaluate test code itself, not necessarily for vulnerabilities but ensure good code quality and prevent bugs from slowing down the testing cycle.
- Deploying: SAST can be used to analyze deployable binaries and libraries. CodeSonar, for example, support binary code analysis for C/C++ code that detects the same types of vulnerabilities as source analysis. This is a good practice to detect bugs introduced during building and deployment of deliverables.
- Monitoring: SAST provide reporting and analysis that software teams can use to evaluate individual warnings but also higher-level assessments of application quality an security. Reports from SAST should be part of the cycle assessment and planning for each cycle.
These integrations into the DevSecOps cycle are illustrated below:
The role of SAST in DevSecOps
Summary
Clearly, there is an important role for SAST in the DevSecOps. Although not a silver bullet when used in isolation, these tools should be used in conjunction with other automation tools. As software teams start to integrate security into their DevOps, tools such as CodeSonar are easy to adopt and become part of the automation pipeline. By detecting vulnerabilities early and preventing them from entering in later stages of the pipeline pays off in reduced late-stage security fixes.
Interested in learning more? Read out guide “Integrating Static Application Security Tools (SAST) in DevSecOps”
{{cta(‘a5a7449d-16cd-4e34-8de4-17c25e039c1b’)}}
