Digital innovation implies more features, services and an ever-growing reactivity from technical teams throughout the whole delivery lifecycle. It is easy to get lost in the resulting layer cake as we multiply the technological bricks and interactions. Besides, frictions often arise between business lines and stakeholders. The cherry on the topping? To try shoehorning security therein, ending up with it being considered an inhibitor rather than a business enabler.
Are we doomed for good? The answer is “nope”—it holds provided we get to look at those challenges pragmatically. Let’s talk DevSecOps then.
DevOps is the agile approach that aligns participants of the value chain and streamlines efforts towards a common goal. Through DevOps, the various business lines come together and articulate the path from ideas through realisation to exploitation. The overarching aim is to enable rapid innovation without introducing frictions and through more fluid interactions between technical teams and business lines.
It would be misleading to pretend that, because people understand the value of the approach, they implement it seamlessly. Take an example: we know that everyone has a test or integration environment. More and more people realise that they need a separate one for running production. Implementing this separation all by optimising each role’s input is far from straightforward. This is especially valid when considering divergent aspirations, where developers aim for new features and ops try to limit them to guarantee stability.
DevOps is the answer in such a context. The approach relies on automating iterative and incremental changes beyond the development cycle to deployment and run. Thus, success-prone practices enable teams to:
- Reduce the time to (business) value, as features coming out of each sprint are directly operational and usable;
- Test and learn with minimal effort, thus helping mitigate risk and optimise quality;
- Adapt rapidly to changing needs;
- Break silos and improve interactions between teams and skillsets.
The key—and often one of the biggest challenges—to those changes is short iteration cycles. Metrology provides continuous feedback. The latter transforms into a productive feedback loop between the different teams. Each of these acts upon the needs within the short cycle.
Those ways of creating technology put the onus of stability and flawless operations on DevOps. Besides, the complexity of such profound changes increases in the context of continuous delivery (CD). CD is the practice of always having software in a releasable state. Thus, when implementing technology ‘the DevOps way’, we embrace the whole lifecycle of an idea which transforms into code that lives through release, operation and feedback on its value into the ideas log (i.e. the backlog).
That’s great and all, but how do we factor security here? Glad you asked—enter DevSecOps.
How do we achieve faster delivery of better digital services posing a minimal risk of abuse to their users? Agile methodologies shake decision-making to its core; this is particularly valid when it comes to articulating security requirements.
No magic there: we can relieve the pressure on stability, to DevOps’ great distaste. Doing so will also impact service quality, which brings other, more significant problems. Or—and much more optimal—we ensure security considerations are factored in earlier so as not to slow down the throughput (from development). DevSecOps, beyond the hype, is how to embed security in the continuous delivery of a product or service. It signals that security is part of the organisation’s way of doing things rather than an add-on.
DevSecOps is, to a vast extent, a matter of changing culture and behaviours. Developers value new features; Ops value stability of operations; and security values as tiny as possible attack surfaces and are often ridiculed as perfect nay-sayers to any evolution. Uniting these opposite aspirations does not strike as easy-peasy.
Hence, a smart way to look at those challenges is people-process-tools:
- Teams need to interact closely, with developers, Ops and security specialists pitching in throughout every iteration. Such timely and continuous interaction outputs better technology and enables nearly-effortless scale-up.
- Rethink security integration that fits and enables short and iterative DevOps cycles. It is crucial to model and support the evolution of the organisation and its major technology processes along with agile approaches. Every time you push code, you potentially add new vulnerabilities to your service. While point-in-time penetration testing is a necessary step, it is not enough as it is too little too late.
- Tool teams up. Automation is an integral aspect of DevOps, and the rate of change in software development has increased dramatically. Beware what you use the available tools for then: SAST comes from a time when only a few languages were in use; hence its value has declined over time. Yet, passing that control point remains a best practice. The vulnerability assessment is another low-hanging security fruit to peruse. Vulnerability scanning automation provides a prioritised list of what needs fixing. Thus, both SAST and vulnerability assessment are solid bricks for your defences; they are necessary yet insufficient.
Going the DevSecOps way is to adopt an approach which takes automation into account and ensures continuous security. Yes, we named bug bounty.
With development and operations processes revolving around a fast delivery cycle, security needs to input relevant feedback loops. Gaining insight into the rapidly-changing runtime environment gives security the ability to collaborate with development and operations to respond to an event before it becomes a threat.
Bug bounty provides the necessary scrutiny your fast delivery cycle requires. A well-managed group of ethical hackers does not boil down to “my code is seen by many eyeballs”. Crowdsourced security is, above all, many creative ways of examining the attack surface, and as many attack vectors, you will avoid falling victim to.
Bug bounty ensures continuous security by providing effortless integration of security reports in the pre-existing DevOps toolkit. Do you use Jira for your backlog? Great then, think of transforming those neat vulnerability reports in Security User Stories for your next sprint. Automating this inclusion is trivial—congrats, here’s to a first step on the DevSecOps path 😉
And it gets better. Think of your CI tests: they pass, even though they often pass like kidney stones. Now, imagine you run them in a bug bounty set-up with your preproduction as scope. Those same tests would be even more useful and fulfilling if you could run them on a platform where scrutiny from security experts is pervasive. And since you have already automated metrology and feedback, you can continue capitalising on that data—for this sprint and the future ones.
And, say, you were wondering how best to secure applications in a web context. In the real world, application-layer attacks often come in forms other than OWASP Top 10. Our ethical hackers spot complex web attack patterns and related business logic errors. Then, our clients leverage defence tooling to fix issues quickly.
We know you are impatient to learn more about protecting the DevSecOps way with bug bounty. Stay tuned for our next instalment! We will discuss actionable approaches to helping you embed continuous security in your CI/CD.
