DevSecOps is just another buzzword for Development, Security and Operations, it's certainly not something new, someone just created a new word for it!
Back in the day, the development, security and operations teams used to live in information silos with minimal cooperation between themselves. The development and operation teams used to look at the security team as the 'mean guys' who would always say NO, give them extra work and wouldn’t let them release their code to production.
With the introduction of the new culture of DevSecOps, the good news is that these information silos are now broken and the teams work much closer to each other with better collaboration than before - security is now a shared responsibility built into the life cycle of your applications.
What do we mean by security is a shared responsibility?
In the past, security was the sole responsibility of the security team and this standard setup would function as a perimeter around your application. The security team would normally just look at the application at the later stages of the development cycle when it was ready to go to production, or worse when the application was already running in production. This would often mean that if there was a security issue, the software development life cycle would need to be restarted, redesigned, redeveloped, and tested again, then the application eventually released, meaning wasted time and extra cost.
By sharing the responsibility of security and integrating it at every phase of the development cycle, 'secure by design', the risk is reduced and the possibility of something going wrong at the last stages of the cycle is minimal.
Although the security team is the subject matter expert (SME), it shouldn’t be their responsibility to review every line of code that gets pushed to production or review every piece of configuration.
The security team is there to advise, help, implement and automate the security practices. Everyone has a responsibility to perform their role with security in mind, that’s why security training is also a critical component.
Another term that goes hand in hand with DevSecOps is 'shifting left', which correlates to the above information. Implement and define your security controls at the earliest possible stage in the pipeline rather than at the later stages. Look proactively to security, instead of it being an afterthought, and get the earliest feedback possible to the stakeholders. For example, if possible, hook in your static application security testing (SAST) tool to the developers integrated development environment (IDE), like this, they get almost instant feedback while they are coding, instead of needing to wait for the security checks to run during the build pipeline. Define your threat model and security requirements during the design phase and validate them during the QA phase.
In conclusion, it’s important that you try to remove the friction between the security team and other teams, you should focus on increasing the cooperation between them. Provide stakeholders with tools to do their job securely without adding extra work and create guardrails not gates, the security team should be an enabler rather than a blocker to the business.
DevSecOps is not just about implementing security checks in the pipelines, although automation is a key concept for a successful DevSecOps approach, it’s the continuous monitoring of your applications for compliance against well-defined standards, guardrails and processes that create a secure foundation for your development process.
Read our latest blog to find out more about enabling DevSecOps
Savanti have a wealth of experience in DevSecOps functions across lots of organisations with the experience to deliver a great security capability. We’d be happy to support you on your cyber security journey, please get in touch – info@savanti.co.uk or visit the chat function on our website: www.savanti.co.uk
