I used a metaphor during a cloud security webinar this week to explain how SecDevOps is an opportunity to “swim security upstream,” an expression that reminded me of an aspect of being a QA Manager earlier in my career. Our software development process included an acceptance phase, which, for repeatability, we executed by running a set of automated tests through a harness. Too often basic mistakes would be found, resulting in the build being rejected and thrown back over the wall to Dev, as it was back in the days of waterfall.
These inefficiencies highlighted the need to swim quality upstream in the dev process by requiring unit tests before release engineering ran a build and handed it off to QA. Just as was the case with such quality assurance steps, so too often are application security best practices performed late in the cycle, if at all. Enter SecDevOps.
Incorporate Security Into DevOps
Intertwined with agile software development practices, DevOps is a methodology based on continuous everything — development, integration, test, delivery and monitoring. SecDevOps — or DevSecOps, whichever suits you — is a term to describe, and frankly, lobby for, incorporating security into DevOps so that security is baked into each step of the continuous DevOps pipeline.
In a cloudy world in which infrastructure is immutable, production isn’t patched; new configs are deployed via a cutover approach, changing how organizations should approach vulnerability management. In a SecDevOps context, test environments that represent the gold image (to cite another old school term) should be scanned for known vulnerabilities, and the gold image updated so that all workload instances provisioned via automated servers are current. Cybric is a new security player bringing repeatability and efficiency to modernize vulnerability management by automating the enforcement of scanning and remediation, highly appropriate for implementing SecDevOps.
Since currency doesn’t mean exploit proof, organizations also need to protect against the risk of zero-day exploits by applying virtual patching controls in production. This approach of detecting anomalous system activity that could be indicative of a compromise piggybacks on DevOps continuous monitoring, representing another SecDevOps best practice. But again, this important application security step is applied later in the DevOps pipeline, so how does appsec cut in line?
Checking Code for Exploitable Vulnerabilities
Just like some of the developers back in my QA days should have been more diligent in writing and executing unit tests before checking in new code, so too should code be checked for flaws that create exploitable vulnerabilities. Veracode, for example, offers integration with IDEs to enable the automated scanning of code so that inadvertently introduced vulnerabilities can be detected and corrected pre-build. Inserting the identification of such coding flaws as part of the DevOps process swims vulnerability scanning even further upstream and represents another SecDevOps best practice.
All of these SecDevOps application security steps are not mutually exclusive, which is to say that both apps and code need to be scanned for known and unknown vulnerabilities from dev to test and in prod. Today’s code-driven digital economy requires that we embrace more proactive measures to reduce the attack surface and SecDevOps represent the opportunity to do so efficiently by swimming appsec upstream.
