As our dependency on software continues to grow, organizations are increasingly taking an agile and DevOps approach to software application development. As a result, the development and operation teams have assimilated, and developers now play an active role in managing the post-production of software.
To meet demands for a faster time to market, development teams are also ‘shifting left’ security, moving it further down the software development lifecycle, with developers increasingly being tasked with building secure software from the outset.
As the resulting DevSecOps process requires developers to take greater responsibility for securing software as well as building it, consideration must therefore be given as to what this means for members of the security team.
Think like builders
One of the benefits of this approach is that, through employing Scrum teams - multi-disciplinary teams with accountability for one application, one micro-service, or one piece of an application - the need for a hand off between teams can be avoided. These Scrum teams are responsible for planning, coding, testing, performance, uptime and now, with the introduction of DevSecOps, they’re going to be responsible for security too.
To succeed in this environment, the first thing the security team will have to do is to start thinking more like builders than breakers. With the evolution of software development culminating in the fully automated pipelines used in DevOps, for example, it’s now almost impossible to think of how to effectively audit security post-production, as opposed to building it in from the start.
Security experts must now consider how they can create a process that will deliver the correct outcome from the get-go, rather than discovering risks and vulnerabilities further down the line.
Test early and test often
Security professionals should work with development teams to identify the earliest point that manual processes, such as manual testing and threat modelling, can be effectively implemented in order to avoid lengthy remediation just before the delivery deadline.
Manual testing, for example, should be done early on in small batches on the features that require it, rather than multiple Scrum teams having to test a lot of functionality just a few days before the software is due to be released. And threat modelling can be done when there’s a design in place; the code doesn’t even necessarily need to have been fully written.
Education, education, education
The AppSec expert will also have to think more about enabling rather than doing. Instead of carrying out tests themselves, or analyzing their findings, they will now have to pass that responsibility on to the development team.
They need to train their teams, empower them to take responsibility for the security testing themselves, and teach them how to deal with the output of that security testing without the need for a security person to weigh in on every occasion.
It’s important to have a process in place that will get resources to a developer as quickly as possible when they’re stuck and unable to fix something.
Developers like guidelines, checklists and templates; they like something they can just pull up and use to get right to the answer rather than having to email or phone someone. When answering a question, therefore, or interpreting a requirement, security experts should consider documenting it in a recipe format so that developers will immediately know what to do in a particular situation. This technique also enables learnings to be scaled across lots of developers.
Create a team of security champions
Security teams can’t be everywhere at once: a majority of companies have a ratio of developers to AppSec experts of 200: 1 or greater. What’s more, while clearly a necessary aspect of the DevSecOps model, many organizations haven’t provided their developers with adequate security training.
In the longer term, every Scrum team should include a knowledgeable security person - that team’s security champion – who should meet with the organization’s security experts on a regular basis.
As the eyes and ears of the security team, the presence of a security champion will avoid situations in which the development team is ignorant of the security implications of a particular piece of coding.
The security champion should recognize when a critical piece of code has been badly written or something hasn’t been correctly fixed, requiring some expertise to be brought in from outside the development team. By identifying these issues, the security champion can escalate the situation and call in the security team at the right time.
Long live the security team
The move towards DevSecOps doesn’t mean the role of the security team is dead. Instead, they need to lead on creating a culture and processes that enable shared accountability. Working with their colleagues in the development team, they need to work out the shared goals, metrics, measurement and reporting that both the teams are going to hold themselves to.
By doing so, they will enable their organization to securely deliver applications at the speed that the app economy requires.