At its heart, cybersecurity is about either identifying, or mitigating weaknesses — a raft of vulnerability management products already exist that can scan infrastructure, network connections, software stacks, and indeed, applications and code, and can potentially recommend fixes, or even apply instrumentation and patches.
Start with On DevSecOps: Putting Security Into DevOps Requires a Risk-First Mindset - Part 1
Note however, that use of these tools doesn't deliver DevSecOps (though it's a start): to make this happen effectively, we need to add the process element. SecOps is an established term to describe operational security practice; DevSecOps brings best practice to the development side of the “Wall of Confusion.” Which raises an important point: be wary of any security tools vendor that claims to have a DevSecOps offering. "Just" having a security scanning tool with an API (so it can be launched from within the CI/CD pipeline) does not a DevSecOps tool make.
However, a range of process support features can help programmers, managers, SREs and so on identify and address security issues before they happen — features such as inline guidance, prioritization of fixes, and integration with repositories/registries so that only “clean” artifacts are deployed.
All of these reduce inherent risk: done right, they do so in a way that aligns with human behavior, for example adding advice in a developer-friendly form. This, too, reduces the overall risk as it makes it more likely for the code to be secure out of the gate.
In addition, a significant element of DevOps is “as-code” in which various aspects of a system and its context can be written textually, and stored under version control, alongside application source. As well as deployment information (which can also be scanned), this can include security policies and profiles, to be taken into account across development and into deployment. The as-code model enables DevSecOps to be policy-driven, and creates an up front opportunity for security and application experts to collaborate, decide, and encode, security measures.
The overall goal of DevSecOps is to give the development process the security it needs, from end to end — security from the outset, rather than laudable, yet somewhat half-cocked shift-left idea (security scanning done earlier is no doubt better but presents an incomplete picture of success).
DevSecOps brings security back into the mix as a first-class citizen — encouraging the incorporation of locks for the barn door early on, rather than fitting them after the horse has bolted. In this way, security can be built in, by design, without being at the expense of agility.
If we could offer one piece of advice, it is to start from the point of view of business risk, and build this into strategy setting at every level
With DevSecOps done right, risks of slow delivery and of future breach can be mitigated in parallel, without seeing one as a threat to the other. And security teams and application teams can work together, rather than feeling like antagonistic neighbors, which reduces risk still further.
If we could offer one piece of advice, it is to start from the point of view of business risk, and build this into strategy setting at every level: the risk of having to fix something later on in the process is just as relevant as the risk of a privacy breach once software is deployed. Security doesn't have to be about prevention, but it does have to be about awareness, that all actions have consequences, not least that a relatively a small investment now may prevent a costly consequence later.
