DevSecOps is one of those things that most product teams aspire for, but few actually manage to achieve. Organisations often dabble in security automation and continuous integration, but few manage to fully espouse a DevSecOps culture in the long-term.
But why is this? And what can companies and teams do to achieve that Holy Grail of 'true' DevSecOps? Like most things in tech, it comes down to a matter of skills.
DevSecOps is a development methodology that integrates security into the rapid release cycles of modern software dev. It emphasises the principle of 'shift security left', which would have security engineers getting involved right from the early stages of development.
It also encourages a close collaboration between members of the product team, from security to developers to DevOps. The chain of events would go something like this:
Under DevSecOps, this would happen at every stage of development (design, build, production) and feature a host of automations to ensure security scans would happen quickly and regularly.
In other words, DevSecOps would make it possible for security to keep pace with engineering, rather than slowing down the entire pipeline.
There are two key reasons why most organisations that attempt to do DevSecOps fall short:
Let's talk about that first one: effort and discipline. Security used to typically be a last-minute effort to clean up a handful of serious bugs before shipping the product. But testing a finished product for security and attempting to fix bugs that late in development will not only leave most vulnerabilities unresolved, but delay the release, too.
That's why it's so important to test and secure every single build—no matter how minor the changes—before it's released. But this requires a significant amount of work to be done: security scans need to be automated, results need to be triaged for false positives, and tickets need to be automatically raised so developers can resolve them.
This continuous integration and delivery (CI/CD) pipeline takes time and discipline to set up and maintain. But the upside of doing this is that going forward, security scans will happen much faster, eliminating delays in the release cycle and resulting in a much more secure product.
The second reason is also complicated: developers lack security skills. Even when they get reports from the security team, they may not know how to fix security vulnerabilities in their software.
This is why companies are increasingly turning to security champions to help them build security competency among developers. Champions are members of the engineering team with an interest in security. These team members are responsible for pushing for better security practices and improving their colleagues' awareness of code hygiene.
Want to train your developers in secure coding? Check out hands-on Playgrounds, where your team can learn to write secure code in their language of choice.
In order to understand the threats to your software and build an effective security program, it's essential build a comprehensive threat model of your application.
"Threat modeling is a technique to document and create a real-world view of the application," says Dinis Cruz, CISO of Holland & Barrett. "One of the side-effects of threat modeling is identifying the security risks, but the most important result is actually understanding how the app works."
A threat model is an excellent way to identify potential threat vectors to your app, determine flaws in the design and architecture, and creating a solid blueprint for security. Your security team can help with the following:
All of these measures can help instil a security-first approach for the development of your software, right from the beginning of the SDLC. In fact, these are key steps to promoting collaboration between your security and engineering teams in the long run.
While security is crucial for any software you develop, it shouldn't dictate the schedule or flow of development. That would be counterproductive, and reinforce the idea that security is an unpleasant bottleneck in the workflow.
Instead, your security program should flexibly adapt to your existing development cycle with minimum disruption. This isn't to say the going will be totally smooth — there will be a learning curve you'll need to overcome when you just get started.
But you should strive to integrate regular security processes like testing, triaging, and remediation right into your development cycle. Security can't be seen as an extra item to add to the list, it's an organic part of the workflow, as important as any other.
That said, you should ensure that the effectiveness of your security activities don't go down as a result.
Automation in many ways is the bedrock of DevSecOps. It's essential to make security fast, regular, and scalable without sacrificing effectiveness. Many processes that are time-consuming and don't require human skill or expertise can easily be automated:
Although automated scans have the risk of generating too many false positives, several tools can help your team quickly find and eliminate false positives. Additionally, dynamic security testing tools like Nuclei use YAML-based templates that allow users to customise scans to their specific use case, thereby significantly reducing the number of false positives.
Combined with less frequent manual pentesting, automated scans can prove extremely effective in quickly identifying and reporting security bugs to developers before every release.
It's a common misconception that application security is purely the responsibility of the security team. But if you think about it, that doesn't actually make sense. After all, your architects are responsible for how your apps are designed. Your developers are the ones writing the code. Your DevOps engineers are managing the entire development cycle.
Each of these roles will benefit greatly from having security knowledge, especially because it will allow them to approach their jobs with a pro-security mindset. Your developers can learn to write secure code, for example, and DevOps engineers can work with security to automated the CI/CD pipeline.
Not only will training your team boost their skills in AppSec, it also improves productivity up to 10-15%. And contrary to common belief, training has a hugely positive impact on factors like employee retention, motivation, and teamwork.
One of the easiest ways to train your entire product team in security is with AppSecEngineer. What sets our courses apart is their emphasis on hands-on learning, which means less boring PPT-style lectures, and more working with your hands. Compared to traditional learning, teams stay much more engaged when they learn by doing.
We have amazing hands-on courses in:
...and 6 more areas of application security.
But there's more: check out Challenges, where you can test your AppSec skills by solving security problems in real-world scenarios.
We also have Playgrounds, which are hands-on environments where you can learn to write secure code in 6+ languages.
To get started with AppSecEngineer, you can start a free trial here, or pick a plan to start training your team today.
Aneesh Bhargav is the Head of Content Strategy at AppSecEngineer. He has experience in creating long-form written content, copywriting, producing Youtube videos and promotional content. Aneesh has experience working in Application Security industry both as a writer and a marketer, and has hosted booths at globally recognized conferences like Black Hat. He has also assisted the lead trainer at a sold-out DevSecOps training at Black Hat. An avid reader and learner, Aneesh spends much of his time learning not just about the security industry, but the global economy, which directly informs his content strategy at AppSecEngineer. When he's not creating AppSec-related content, he's probably playing video games.
Contact Support
help@appsecengineer.com
1603 Capitol Avenue,
Suite 413A #2898,
Cheyenne, Wyoming 82001,
United States
.svg)
.png)
.png)
.png)
.png)
