As DevSecOps become more complex – with various IDE platforms, coding languages, open source components, multicloud environments, and so on – the risk of potential breaches, vulnerabilities and compliance violations increases. Therefore, it is imperative that CISOs, CIROs and general cyber security risk managers continue to step up to the challenge of adapting to DevSecOps that are constantly evolving.
This puts significant pressure on security teams to manage security findings, secure infrastructures, developments and sensitive data while adhering to regulations in complex environments. More importantly, this is all to be achieved while keeping pace with compressed release cycles along with finite expertise, resources, budgets and tools.
It is worth keeping in mind that you will also have to secure the physical data store itself and not just the DevOps deliveries to avoid your environment being the target of a ransomware attack, a major leak of code or, even worse, a customer data leakage.
Securing DevSecOps often falls into the hands of developers. Requirements signed off in sales bids for things that may not have been done in the past somehow land on innocent developers’ desks. A common remark echoed through all development teams is “that’s not our job” and traditionally, in the past, it wasn’t because code was built to work, not to be secure.
Standard DevSecOps fails to integrate security needs and stakes into processes. There is often no consideration on how their releases and changes affect security – or, worse, teams are under pressure to rush releases and to gain time bypassing security needs.
Security reviews can sometimes be treated as an afterthought, often on a purely compliance approach and performed late in the process, if at all: “the auditor is in tomorrow, quick do some cyber security!” This nearly always leads to delays in delivery when substantial last-minute mitigations are needed to address security findings. This is time-consuming and it’s extremely likely that your team won’t be able to keep up with the pace of deployments and environment changes without taking lots of shortcuts.
Since slowing down isn’t an option, you need to propose a security strategy and model that is development and DevSecOps-friendly. An integral part of the entire app lifecycle is identifying and remediating security issues as early as possible. This also saves costs, avoids rework and reduces risk by ensuring deliveries are secure before they are deployed. That’s what DevSecOps aims to do.
DevSecOps allows you to take into account cyber risks, drive better security practices, offer security dashboards and provide reporting enriched with full context and integrate this into developers’ tools and processes. This unifies security across cloud infrastructure, data protection, and application deliveries.
The key to success is to ensure that everyone in the delivery pipeline shares accountability for security and everything is as automated as possible with accountable stop gates.
The core of your DevSecOps strategy will rely on a security baseline, Common Vulnerabilities and Exposures (CVE) tracking and a risk tolerance definition paired with a risk/benefit analysis for security deviation request and security issues management. CVEs can be the backbone of your DevSecOps. Your app will definitely have dependencies – it might be Java, Apache, or even something like Log4J, all of which could significantly compromise your app’s security.
So, what security level is necessary for a given app regarding its attack surface? How important is speed to market? Your strategy needs to be defined jointly by security team/delegates in direct communication with business stakeholders and DevSecOps teams. It will help to build-in information security and set a plan for security automation to achieve real secure-by-design delivery.
There is a need to help developers code with security in mind. To do that, a process that involves security delegates sharing threat intelligence, best practices from industry standards like OWASP or CIS and an understandable security baseline is key. Introducing security training for developers and operators can be useful since it hasn’t always been a focus in more traditional application development.
CVEs can be notoriously tricky to follow and some applications could have seen decades of developers working on them. There may be dependencies which are 10 years old hiding in your app, which the newest developer has no inkling about, “but it must be there for a reason”, right? When a new CVE surfaces for such a dependency, it’s possible you might not even notice. Who is looking for security notifications from that vendor? Probably no one. Automation is key to this. Nesting CVE checkers into the pipeline to do those checks autonomously is imperative.
To help security and non-security personnel make informed decisions, your DevSecOps tools will also need to identify and correlate multiple factors to be integrated with IT service management tools. However, effective DevSecOps requires more than new tools. It requires a cultural change to integrate the work of security teams sooner rather than later.
One of the biggest challenges is cultural change. DevOps teams are under huge pressure to maintain a rapid pace and are very likely to say that security is “slowing them down”. On the other hand, security teams or their delegates are primarily focused on securing apps, code, infrastructure and data. In other words, it’s difficult to work together when teams’ goals are divergent. You need to unify their goals and show them the long-term, cross-team benefits of DevSecOps.
With better collaboration and a better understanding of cyber risks and threats, your team will be better equipped to implement much-needed guardrails for developers to incorporate into their daily work, reducing friction between the teams. As an example of better communication, keeping your developers informed about security findings such as vulnerabilities, configuration errors and incidents, helps them to understand the value of security.