We’ve pulled together an FAQ on DevSecOps, so you can give some thought on whether this approach might be beneficial in your organization. We hope it’s useful.
What is DevSecOps?
The concept evolved from its predecessor DevOps, a portmanteau for Development and IT Operations (Dev + Ops). I have also heard it referred to as “Agile on steroids”. The idea is simple: it bridges the gap between development and IT teams through collaboration to reduce project redundancy, increase automation, shrink resource and time requirements…. Basically, it is designed to radically speed up the time it takes to develop a process.
Now this makes great business sense, but it was a nightmare for security. The faster build times shortened the time they could test and strengthen security.
Enter DevSecOps. The idea is to make information security a key feature from the get-go. It was introduced to combat the problem of development teams often tacking on security, almost as an afterthought.
DevSecOps requires baked-in security, meaning it needs to be a priority from the start of the project.
For the last decade or so, the concept of DevSecOps has been evolving, with more organizations reaping the benefits of DevsecOps.
So, it is not just an industry buzzword?
It would be a pretty bad one if it was – it’s not a very catchy title. The reason it has caught on is multifold.
A growing number of cyber regulatory bodies (think GDPR, HIPAA, PCI) require evidence of security being baked into processes and services in order to better protect the data as well as the people: shareholders, employees, business partners, and of course customers.
Companies with established DevSecOps programs and strategies address flaws faster than those without security procedures. Veracode research shows that “Active DevSecOps programs repair flaws more than 11.5 times quicker, because of regular security checks during continuous deliveries of software builds according to recent research”.
Just what are these benefits of DevSecOps?
Here are a few:
Cost reduction – by detecting and addressing security issues during the development phases
Speedier recovery – having clear steps to follow in a specific incident – from vulnerability report to a breach
More resilient product or service – with security baked in, there are fewer vulnerable components available for bad agents to take advantage of
Speedier development – using immutable infrastructures means you can automate and simplify the code structure
‘Secure by design’ principle – helps to drive developers to always think security
How big is the DevSecOps market?
According to one analyst, Research and Markets, “The DevSecOps market size is expected to grow from USD 1.5 billion in 2018 to USD 5.9 billion by 2023, at a Compound Annual Growth Rate (CAGR) of 31.2% during the forecast period”.
What is pushing it forward is not only the increase in big breaches hitting the headlines, but also the need for secure application delivery. Compliance regulators demand it, a few business partners will see it as a deal-breaker, and even some customers will request it, depending on the industry.
A few things that are holding back growth is the need for highly skilled professional to head up the DevSecOps programme, and the fear from organizations that change leads to disorder.
Some factors to consider when injecting security into DevSecOps?
Security checks: All DevOps processes and technologies have to be manually and automatically reviewed before implementing security elements into the DevOps lifecycle. Be prepared to fix the broken processes and remove non-secure technologies.
Collaboration: Dev, Sec, and Ops need to work together to ensure that security checks and automated tests are fused into the DevOps lifecycle.
Speed and security: While DevOps folks will undoubtedly complain adding security elements will slow down the software delivery process, this should never be the case. When it comes to DevSecOps, there should be no tradeoff between speed and security.
Automation: Security teams are typically concerned about adopting automation practices. That said, they should bear in mind that security automation helps achieve both speed and security while allowing for security checks on a regular cadence.
Move Left approach: DevOps should be ready that security teams will start to move-left their security processes toward the inception and design phases, which may cause disruption in the DevOps practices.
Developers self-education: The introduction of security into DevOps can be technologically challenging. Developers should almost always have a say in the process. Developers will need to work to acquire software security skills and implement best practices.
Are there any well known companies that have implemented DevSecOps?
Yes – many. Here are a few of them:
Paypal embedded several repeatable proactive security practices in their product life cycle.
“We wanted to make it incredibly hard for our developers to shoot themselves in the foot when it comes to security,” said PayPal’s Laksh Raghavan, Senior Security Strategist in Information Risk Management.
DevSecOps let Fannie Mae use “tools and strategic initiatives to deploy new systems to get feedback, go live in production, and remediate vulnerabilities within the development process” much more quickly. According to Vulcan, DevSecOps helps Fannie Mae build trust and regain confidence from its customers.
Microsoft is very proud to run DevSecOps. As their webpage introducing the concept puts it, “development and operations are tightly integrated to enable fast and continuous delivery of value to end users. DevOps has replaced siloed development and operations to create multidisciplinary teams that work together with shared and efficient practices, tools, and KPIs. To deliver highly secure software and services in this fast-moving environment, it is critical for security to move at the same speed. One way to achieve this is to build security in development (SDL) and operations (OSA) processes.”
Any final tips for implementation?
Always keep in mind the risk level you need to attain. The product or service cannot be, and will never be, completely impermeable to bad agents. Your job is to assess the threat and the acceptable risk for each sensitive element. I call this the 80/20 rule. Many can get bogged down in the weeds with very unlikely use cases.
Test test test. So you have implemented a new process. Test it. Do not assume you know how things will behave in the real world until you test its functionality.
Manage the pressure and know what you are accountable for. There is always a lot of pressure to get things out on deadline, but cutting back on essential security implementation or testing will only serve to hurt you and your career prospects later on.
Do not hide stuff thinking it will never be uncovered. Be transparent. If there is a problem, communicate it succinctly and as early as possible so it can be rectified in a collaborative, and maybe even automated, way.
Want to know more?
Get in touch with TBG Security. We have TBG Security DevSecOps specialists across the United States. And we are here to help.
