DevOps has transformed the way enterprises function. Companies are going to market faster with innovative products and achieving greater savings along the way. However, with cyberattacks on the rise, organizations can ill-afford to ignore the security aspect of the DevOps model. The Equifax data breach of 2017 is one of the many examples that shows how necessary it is to introduce security checks into the production process. An unpatched vulnerability cost the company a mind-boggling $700 million in a US data breach settlement.
An IDC survey revealed over one-third of businesses worldwide experienced a breach in the past 12 months. In another report, 71% of CISOs believe that their code is not free of vulnerabilities before going live in production. These figures are worrying.
Teams need to adopt DevSecOps for a secure infrastructure without compromising on speed or productivity. In the rapidly iterating world of DevOps workflows, security can no longer be an afterthought but has to proceed side-by-side with application development. In fact, the quicker security is introduced into the SDLC, the better it is for the organization’s overall health.
“DevSecOps isn’t about perimeter security around apps and data, but is about building end-to-end security into your apps,” notes Cloud Advisor Kevin Davis at CloudReach. “Doing this leverages the software and systems logistics chain to identify security vulnerabilities quickly to reduce the risk of negatively impacting customers and minimize the possibility of cyberattacks and downtime. Overall, with DevSecOps, companies can efficiently merge collaboration and communication among development, operations, and security teams. It’s a win, win, win.”
What is DevSecOps?
DevSecOps is a software methodology that incorporates security into the existing DevOps cycle. DevSecOps upends the traditional SDLC by introducing security protocols into every step of the SDLC process. As a result, teams deal with security threats when they arise instead of responding to them later in the development cycle.
Earlier, software releases were few and far between. DevOps shortened the SDLC to days. In such a scenario, having a security team test the code in production creates unnecessary delay and defeats the very concept of fast and agile DevOps. Secure and fast product release is possible only with a fully automated SDLC. Implementing DevSecOps enables businesses to innovate securely while being agile at the same time.
Key Elements of DevSecOps Implementation
Sean Wright, lead application security SME at Immersive Labs says, “You need to really commit to DevSecOps. This means having security throughout the process’ lifecycle, having the appropriate and right tooling at the right stages, and most importantly, equipping your staff with the right knowledge and skills to consume those tools and prevent and fix security issues. This ultimately helps allow everyone to have a part to play in the security of an application or service.”
Given below are some best practices that you need to keep in mind when implementing DevSecOps in your organization.
Cybercriminals can exploit vulnerabilities in your code; therefore, detecting them at every stage of the CD pipeline is crucial to DevSecOps. But given the quick turnarounds for faster deployment, manually combing through vulnerabilities is well-nigh impossible.
Automated vulnerability scanners improve your security posture and prevent cyber threat actors from exploiting vulnerabilities in your system. Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) are the most well-known automated technologies used to protect applications.
Developers use SAST during the initial phase of the SDLC to examine their source code for possible vulnerabilities. DAST is a black box approach to testing where DAST tools act like hackers and attack an application once it’s up and running.
DAST tools come up with a lot more relevant results than SAST tools that often report a lot of false positives. Together, SAST and DAST work to protect your applications — both in pre-production and production environments.
Interactive Application Security Testing (IAST) is a relatively recent technology approach that “instruments” the code and monitors your application when it is running. An agent deployed within the application monitors it and identifies security loopholes overlooked by SAST and DAST tools.
Asaf Karas, JFrog Security CTO, suggests that “package vulnerability scanning is a basic step towards securing virtually any modern software delivery pipeline. By automatically identifying known vulnerabilities within each package used to deploy an application, package scanners can significantly reduce the risk of putting insecure software in production. It’s also wise to invest in a comprehensive vulnerability database because the public vulnerability databases like MITRE CVE or the NIST National Vulnerability Database don’t always include the latest threat information.”
Switch to Immutable Infrastructure
Immutable infrastructures are a crucial component of a secure DevSecOps pipeline. Unlike mutable infrastructure, immutable infrastructure eliminates configuration drift, thus making it easier to diagnose vulnerability issues. If an immutable server is compromised, developers don’t have to patch it; instead, they replace it with a new one.
“Immutable infrastructure is directly tied to the use of infrastructure-as-code that codifies the entire application architecture,” explains Aakash Shah, CTO and co-founder of oak9. “With infrastructure-as-code, companies can shift-left even further to ensure that security, stability, and quality are designed in by scanning and remediating design gaps.”
Kate Adam, Juniper Networks‘ Sr. Director of Security Product Marketing believes that though “immutable infrastructure is a very nice idea, it is unrealistic to implement everywhere because an organization’s applications are likely at different levels of maturity. And many do not have adequate time built into their planning cycles to account for working out all server requirements that will ever be needed — and hats off to orgs that do this!”
Adam adds, “However, when teams can make applications stateless, it’s much easier to implement immutable infrastructure, and it absolutely should be done. When infrastructure is locked down in this way, attackers have an even more difficult time exploiting it and application services running on it.”
Runtime protection is crucial to successful DevSecOps implementation. Runtime Application Self Protection (RASP) is a promising technology that does not just offer signature-based detection but is effective in diagnosing vulnerabilities and warding off attacks in real time.
RASP instruments the code and is placed along with the vulnerabilities in an application. The deep visibility into application layers enables it to offer highly accurate assessments of malicious attacks, eliminating false positives. With RASP appropriately implemented, the code is already built to self-protect.
However, Aqua Security’s VP of Product, Story Tweedie-Yates points out that “currently, there is a big knowledge gap around runtime security and recent research has shown that it is not being emphasized enough within cloud-native security initiatives. Organizations need to invest in runtime protection because without it, other critical elements of its cloud life cycle security strategies — including shift left, hardening, and scanning — could be void if attackers gain access to the production environment.”
Secure Container Images
Containers are commonly used in the DevOps environment as they ensure continuous deployment and continuous delivery. Nevertheless, they can pose certain security risks from the DevSecOps perspective. Container images may contain vulnerabilities, especially those that originate from public repositories. Therefore, any DevSecOps process must secure container images throughout the CI/CD pipeline stage.
There are several ways you can do this for a robust security stance:
- Use small base images. This one is simple. The smaller the size of image, the less is the attack surface area.
- Use image scanners in all stages. With vulnerabilities being discovered every day, it is safer to use image scanners at every stage of the CI/CD lifecycle.
- Never run images as root. Running container images as root can be a costly mistake for developers. Threat actors with root access can do irreversible damage to your organization.
A Change in Company Culture
DevSecOps introduces security practices within the DevOps framework, calling for greater partnership between the security and the engineering teams. But that is easier said than done. The fact is development, operations, and security teams work in silos. Bringing them together under a single ambit turns out to be complicated.
With company culture deep-rooted across all business areas, simply adopting DevSecOps practices will not bring about organization-wide transformation. Instead, leaders must create systems that work for their respective teams and foster a culture of collaboration among them.
There is no one-size-fits-all thing in DevSecOps.
“DevSecOps have to be very familiar with development processes and methodologies,” Adam says. “They have to know security very well, and they have to be both diplomats and security ambassadors to be effective in their roles. DevSecOps is not a product or specific set of technology — it’s a role that needs a human because software development processes are different at every company and software is different at every company.”
Despite the benefits that DevSecOps offers, many organizations are still doubtful about adopting DevSecOps. Just like DevOps, DevSecOps requires a paradigm shift in thinking. Businesses need to realize that security is everyone’s responsibility and not just that of the Infosec team. Implementing DevSecOps will not be easy, but the change will be well worth it.
Read next: Best DevOps Tools & Software of 2021