Can DevSecOps Cover Holes Created by Digital Transformation?
Software Development Lifecycle (SLDC) is constantly improving, thanks to the availability of new ideas, tools, technologies, and mainly the formation of open source communities, driven by individuals and corporations alike. These tools boost business productivity and operational efficiency.
Continuous deployment, where the SDLC is automated end-to-end – from the build, provisioning and even vulnerability scanning, all the way to the release and deployment of new applications, functions and versions – helps organizations take a major leap forward as far as resource utilization and time to market go. However, organizations, while keen to adopt new frameworks, are behind with figuring out how to adjust business process and areas of responsibility.
Many data breaches and successful hacks lately took advantage of vulnerabilities in applications or APIs that were overlooked during development process.
The DevOps Security Conflict
72% of executives say information security is a weekly discussion topic in management meetings. With all due respect to awareness and top down initiatives, the devil’s in the details.
[You may also like: Application Delivery Challenges for DevOps]
The challenge for DevSecOps is building embedded security from the bottom up, where security folks are considered showstoppers. While organizations are moving forward with digital transformation – boosted now by the COVID-19 pandemic – DevSecOps is a new role. It demonstrates businesses’ understanding that they need built-in security, beyond technological solutions only, by bridging between the gap between conflicting agendas of the application builders and its defenders.
DevSecOps are usually application security experts who work as part of the application development team to write secure code. However, two in five organizations have yet to hire a DevSecOps expert.
According to Radware research, only 32% of CISOs have the final say regarding selection of security tools to be integrated in the CI/CD pipeline, and they are fourth in line when it comes to the actual implementation, after IT staff, the app developer and DevOps.
The Trust Factor
This bias is becoming stronger, given the positive sentiment DevOps and app developers have towards opensource code (67%), microservices (68%) and serverless frameworks (73%), which are generally perceived as more secure by default. In addition, 70% of web applications are modified at least once a week.
[You may also like: How to Move Security Up the DevOps Priority List]
With that said, it’s no wonder 56% of enterprises do not integrate security into their CI/CD pipeline. This tells us that dev teams prefer going back to deal with possible vulnerabilities and risks after the fact, when they are most likely busy working on another mission. In other words, security is not built into the app, and it doesn’t bubble up.
This is exactly why 72% of executives talk about information security issues on a weekly basis. They understand that the cost of cyber attacks is simply too great to not succeed in mitigating every threat, every time. Customer trust takes years to build but is obliterated in moments, and the impact is significant on brand reputation and costs to win back business.
Customers are increasingly wary of accepting promises of information security at face value. Every time consumers interact with a brand, they make a judgment about whether they trust a company enough. As we discussed in our 2018-2019 Global Application & Network Security Report, successful cyber attacks break the trust that companies have worked hard to establish between their brands and customers.
Ramifications are no longer the sole responsibility of security professionals, and dev teams should be just as accountable.
3 Required Skills Beyond Just a Security Background
Therefore, integrating a DevSecOps engineer into the team is a great first step. However, they should be given the tools to make an impact – i.e. releasing safer code that is scanned for vulnerabilities, has embedded access controls, sanitizes sensitive data and so on, with the end goal of indeed building and delivering safer software products.
Achieving that goal requires more than just an application security background:
- Interpersonal relationships skills are just as important as technical skills, such as writing code or architecting software. We are talking about conflict management and the ability to get everyone – peers, managers – around a common goal, and find the right balance between business productivity and security.
- Familiarity with as many as possible CI/CD tools. Since every team utilizes different tools and every DevOps leader designs a different architecture for their CI/CD pipeline, not every security solution will fit. When it doesn’t fit in, it causes disruptions, slows down time-to-release processes and leaves the company vulnerable. Even best of breed security solutions do not always integrate seamlessly into the CI/CD pipeline, and DevOps would usually prefer seamless integration over security effectiveness. Which is all to say, the DevSecOps engineer must have a mental array of security tools and their interoperability (i.e. integration options) with common technologies that are used in different dev environments. The ability to quickly integrate security measures into the CI/CD pipeline processes is what DevSecOps are about.
- Threat Modeling. A security background is a good start, especially since in many cases, DevSecOps are organic software engineers that assumed security responsibility. But to excel, threat modeling knowledge is key – going over the design to find vulnerabilities in components and data flows, to later map possible threats (STRIDE is a good start) and eventually prioritize the security controls and solutions to deploy.
[You may also like: Are Your DevOps Your Biggest Security Risks?]
The success of DevSecOps is very much dependent on the understanding that the role isn’t only technical but also procedural. They are the ones who can facilitate bottom up security to meet the expectation coming from the top down. Launching applications based on safer code will not solve all security risks, but it will at least nurture customer trust.
