DevSecOps is an efficient way of creating secure software. It involves elevating security at every point along the software development lifecycle. This contrasts with more traditional development philosophies, where security is often an afterthought.
The name "DevSecOps" is an amalgamation of "development", "security", and "operations". It builds on the DevOps philosophy - and in many ways, it's the last piece in this puzzle. By putting security on everyone's agenda, release velocity is increased.
DevSecOps grew out of the DevOps movement. Generally speaking, DevOps doesn't concern itself too much with security - leaving it as a potential bottleneck. DevSecOps is an updated version of the DevOps philosophy, which fully integrates security into the pipeline.
Some of the basic tenets of DevOps are described in "The Three Ways". Popularized by the seminal book The Phoenix Project, these are (broadly speaking):
1. Work always flows from "left" to "right". That is, from dev, through ops, to the end user - never going backwards. Ways to maximize flow include: making updates little and often, ensuring updates don't pass errors to the "right", and constantly optimizing processes in light of organizational goals.
CI/CD technology plays a major role in the First Way. A CI/CD pipeline enables an agile, granular approach. It's said that IT infrastructure at this point "becomes code".
2. Fast feedback from "right" to "left". This leverages the fact that errors are cheaper and easier to fix earlier in development. If you've ever heard of "shift left" testing, then this is what it refers to. The idea is to create quality code from the outset.
3. Creating a culture where experimentation, innovation, and even a little risk taking, are encouraged. This allows you to try new things - "failing fast" where necessary - learning from any mistakes along the way.
DevSecOps involves a number of processes, but hinges on the power of software automation. By automating security, DevSecOps tools give developers fast feedback, right when they need it. This increases delivery speed, because (as above) the sooner a bug is found, the faster (and cheaper) it is to fix.
CI/CD technology is key to making the DevSecOps concept work in the real world. So it's unhelpful to think in terms of "DevSecOps vs. CI/CD" - because they both go hand in hand.
Developers give DevSecOps the thumbs-up because it makes their job easier. Security staff love it, because it stops them getting swamped with easily-fixed bugs. And it makes executive management happy because release velocity and security are increased.
What's more, by using a scalable solution, you can ensure that the size and cost of your DevSecOps deployment is tailored to your needs. This helps you optimize performance and ensure your automation is as effective as it should be.
On paper, you could be forgiven for thinking that DevSecOps shouldn't work. If you're used to releasing in monthly - rather than (say) hourly - cycles, a huge increase in release velocity could sound totally unachievable.
But the rewards are potentially huge. If your organization can drop a killer new feature in three weeks instead of three months, then it could give you a real edge over your competition.
There are a number of ways DevSecOps helps increase release velocity. The first of these is a virtuous cycle inherent in regular release patterns. DevSecOps gives developers timely feedback - so they can "fail fast" where necessary. If a dev creates a vulnerability, their head is still in the game by the time it's flagged. This allows them to fix the bug and learn from it.
With DevSecOps, you can feel confident that new releases don't leave doors wide open for hackers. While the top level of security will always require manual pentesting, automated vulnerability scanning of each release you make, aims to catch the most critical bugs. DevSecOps is the most secure way to get the agility your organization needs.
DevSecOps security is a continuous process. Gone is the security "gateway" (many would say "bottleneck") of traditional development. As above, application security is integrated with development processes. Developers receive timely feedback on their code - empowering them to write secure code even without cybersecurity expertise.
The ability to produce secure code in this way is a primary goal of DevSecOps. Its processes should be robust enough to run without any need for intervention by security professionals. Developer education is key to this - and should be an ongoing process within DevSecOps.
The best DevSecOps security tools train developers in effective security techniques while also making their life easier. At PortSwigger, we believe the best way to do this is through timely feedback written with developers in mind. Developers learn on-the-fly - putting their newly-honed skills to work immediately.
See more customer stories
Currently, Burp Suite Enterprise Edition helps us to have an attractive value proposition for our clients with DevSecOps scenarios. Dynamic testing gives very good results versus other solutions. Source: TechValidate survey of PortSwigger customers
Head of Consulting
DevSecOps means software gets released with a basic level of security built in. But detection of certain vulnerabilities can still require penetration testing. This more manual step will generally happen shortly before or after development - and is crucial for effective DevSecOps.
While penetration testing can reveal advanced vulnerabilities, it's not a quick process. A worldwide skills shortage also makes it difficult to carry out at scale. Conversely, vulnerability scanning is fast and gives broad coverage, but can lack depth compared to manual testing. Each has benefits and drawbacks - and DevSecOps security best practice demands both.
This approach is of great benefit to organizations with many applications to secure. While blanket penetration testing at this scale may be impossible, DevSecOps allows for an acceptable level of security to be achieved before release. Manual testing can then be carried out on a priority-based approach.
For most organizations, DevSecOps will require a shift in culture. It's probably not something that will happen overnight. But by making DevSecOps your goal, you're sure to achieve a lot of progress along the way.
Some actionable steps you can take toward implementing DevSecOps, no matter where you're up to, include:
Beginning to scan your whole estate at a higher frequency is a strong step toward DevSecOps. This will help you to find your security "open goals". Security experts shouldn't have to spend their time identifying bugs a scanner can find. Scanning at scale frees up security time to be spent on more suitable activities.
DevSecOps promotes friction-free processes. Scanning solutions should be technology agnostic wherever possible, to allow innovation and agility in development. Likewise, a scanner that requires difficult, unreliable instrumentation before it can be run, is unlikely to be embraced by developers. Aim for a flexible solution that produces few false positives.
We've seen that a key principle of DevSecOps is to shift security "left" - toward development. This makes bugs cheaper and easier to fix. Educating devs in security principles is a great way to kick-start this process. And free resources like PortSwigger's Web Security Academy help a lot.
Fast feedback loops are core to any DevSecOps implementation. Developers should find out about vulnerabilities soon after they've created them - in language they can understand. This allows them to learn from previous mistakes - and to avoid pushing security bugs to the "right".