What is DevSecOps?
DevSecOps Defined
DevSecOps principles and practices parallel those of traditional DevOps with integrated and multidisciplinary teams, working together to enable secure continuous software delivery. The DevSecOps development lifecycle is a repetitive process that starts with a developer writing code, a build being triggered, the software package deployed to a production environment and monitored for issues identified in the runtime but includes security at each of these stages.
DevSecOps best practices should ensure that security is an integral part of the software development lifecycle. The process repeats as new features are developed and bugs fixed. To develop and release faster, developers are reliant upon open source software to complete their projects. The typical modern application is made up of up to 90 percent open source software. This has the potential to introduce the following into an organization:
- Security vulnerabilities
- License compliance issues
Relying on developer reports and manual processes only provides a partial picture. Hence, security and compliance are an essential part of the DevSecOps process.
There is an existing ratio of 200:5:1 developers to operations to security people. This means that any security issue identified by a security vulnerability scanning tool needs to be reviewed by a very small security team that may even lack the technical knowledge. This challenge can be reduced by shifting left to the developer and operations teams, making them also responsible for security and compliance, and moving security earlier in the SDLC process.
Implementing the identification of security issues earlier in the CI/CD pipeline, as well as automating security and compliance policies in the Software Development Lifecycle (SDLC), rather than using manual processes, is crucial. Moreover, organizations that leave the Sec out of DevOps, may face security and compliance issues that are closer to their release, resulting in additional costs for remediating such issues.
Get started with JFrog Xray for FREE and scan for security vulnerabilities
Start Free
DevSecOps Culture
A DevSecOps culture is one in which everyone takes responsibility and ownership of security. Blending in with the best practices of DevOps, each development team should assign a security champion to lead the security and compliance processes and actions in the team to maximize the security of the software that is delivered.
The nature of DevOps is to automate as much as possible to prevent human errors and create automated gates to prevent having unstable code getting into production. In essence, code with a security vulnerability or a non compliant license is unstable.
DevSecOps Principles
Introducing and implementing DevSecOps to an organization requires cultural and operational changes. Including: security training, tools and resources. Here are some useful concepts when making the shift in your organizational culture.
-
Security champions
These team members are responsible for the overall security aspects, making sure they are implemented in the DevOps pipeline, and exposing them to other members of the team. For example, A development team security champion will lead the implementation and usage in the team of:
- Static Application Security Testing (SAST), to discover security flaws in the source code
- Software Composition Analysis (SCA) for visibility into open source dependencies.
A QA team security champion will implement:
- Dynamic Application Security Testing (DAST) as part of automated QA cycles.
-
Security as an integral part of the process
DevSecOps practices require security as part of the SLDC, rather than just before software is released to production. This means that developers integrate security scanning into the build process, as well as their IDE environment to identify vulnerable dependencies.
-
Easily accessible data
Developers outnumber security professionals by 200:1. Using dedicated IDE plugins, can bring security data directly into the tools developers are already using, making it simple to adopt. Introduce best practices for developers on how they can avoid security issues as they write their code.
JFrog Xray puts security at the developer’s fingertips by providing security vulnerability information about dependencies used in the code.
-
Automated Governance
In addition to manual checks, such as code reviews, security checkpoints can be distributed at each phase of the DevOps pipeline to determine if your software can continue to the next phase. A governing system can automatically enforce company policies, and be able to take action accordingly without intervention:
- Notification of security or compliance violations (Email, Slack, Instant Messages, Jira, etc.)
- Blocking of downloads
- Failing of builds that depend on vulnerable components or fail to comply with license policies
- Prevention of the deployment of vulnerable release bundles
JFrog Xray can be integrated with any CI server to fail builds if security vulnerabilities or open source license compliance violations are found in any build artifacts or dependencies.
DevSecOps can be automated into your pipeline, creating an abstract overlay of security.
DevSecOps Tools
There are several families of security and compliance tools to address different aspects of the SDLC. This includes: Static Code Analysis (SAST), Software Composition Analysis (SCA), and different approaches for testing the code for vulnerabilities (DAST and IAST). In addition there are tools that are aimed to monitor and protect your binaries in production environments against attacks that exploit your code or your environment vulnerabilities. Ideally teams should aim to adopt all of these areas for complete SDLC security.
Static Application Security Testing (SAST) tools can help you in identifying vulnerabilities in your own proprietary developed code. Developers should be aware of and use SAST tools as an automated part of their development process. This will help to detect and remediate potential vulnerabilities early on in the DevOps cycle.
Software Composition Analysis (SCA) encompasses managing and monitoring license compliance and security vulnerabilities in the open source components your code depends on. Knowing what OSS components are being used and what their dependencies are of primary concern. After identifying the open source components, SCA tools such as JFrog Xray, will provide information on licenses and whether there are any known security vulnerabilities associated with these components. Advanced SCA tools offer policy enforcement capabilities, preventing the download of binaries, failing builds, and notifying other systems.
Dynamic and Interactive Application Security Testing (DAST and IAST) tools test the running application’s exposed interfaces, looking for vulnerabilities and flaws. While DAST looks at the application as a black box, IAST uses instrumentation that combines dynamic application security testing (DAST) and static analysis security testing (SAST) techniques to increase the accuracy of application security testing.
Container Runtime Security tools monitor the containers in their runtime environment. Such tools provide different abilities including – fire walling on different levels, identifying anomalies based on behavioral analytics and more.
Best Practices for DevSecOps
- Train development teams to develop secure code
- Track security issues the same as software issues
- Security as code, Security Built In
- Integrate security controls in the software development pipeline
- Automate security tests in the build process
- Detect known vulnerabilities throughout the pipeline
- Monitor security in production
- Inject failure to ensure security is hardened
Source: The Divine and Felonious Nature of Cyber Security – John Willis @botchagalupe
The DevOps Handbook, Gene Kim, Patrick Debois, John Willis, Jez Humble
FAQ
What is Software Composition Analysis?
The need for Software Composition Analysis (SCA) grew out of the increasing use of open source software components, used by developers to keep up with the pace of innovation. Companies were struggling to manage and keep track of open source usage across teams and sites and needed a more automated way.
Open-source software typically makes up 90% of an application's code. It is critical to make sure this part of your code is managed and secure.
Too many companies overlook the risk of open source components while focusing only on the code they write. This can lead to notorious security and license breaches costing companies millions of dollars such as Equifax and Capital One. An SCA solution can fix that!
SCA encompasses managing and monitoring license compliance and security vulnerabilities in open source components. Knowing what OSS components are being used and their dependencies is a primary concern. After identifying the OSS components in an organization, SCA tools provide visibility into each component, including information on the license, it’s version number and whether there’s any known security vulnerabilities associated with it.
What are the risks of using open source components?
Modern applications are now composed of up to 90% OSS components. This means the majority of the software we are building, deploying and consuming on a daily basis, is more likely to contain vulnerabilities than ever before. Because it’s open, hackers have easy access to see the code and can look for vulnerabilities. Not only does open source software pose a risk through vulnerabilities, but it can also introduce complex licensing compliance issues for organizations. A potential complication could be that a license says “if you use this component, you need to make your code open source.”
Ideally you want to scan and Identify license compliance and vulnerability issues on all of your OSS components as early in the development process as possible. Knowing what components you have across your entire application portfolio and keeping track of them is an absolute must and should ultimately be automated. This should be an integral part of your CI/CD pipeline, to keep your development and release velocity on track.
Historically, securing across your SDLC and into production required running agents to do component scanning. Today there are different solutions that can achieve a greater level of security and compliance monitoring, that are integrated directly into your IDE, repository manager, CI/CD pipeline and can even scan your container images. For open source security and compliance monitoring, having a natively integrated SCA solution would work best.
What do SCA tools offer?
Advanced SCA tools offer policy enforcement capabilities, enabling automated monitoring of open source components. These are configurable to enable different behaviours on identified security or compliance violations, based on the context of what is being scanned. An example would be to fail a build of a highly sensitive application based on a vulnerability, while not failing the build of a test application with the same vulnerable component. SCA tools compare every open source component in your code against your policies, and trigger different types of automated actions depending on the result.
An SCA tool uses a reference database of known vulnerabilities and licenses with which to compare the OSS dependencies being used by your application. The more comprehensive the databases, the lower the risk of you having any known vulnerabilities or licensing issues in your production code.
What are the key considerations when choosing an SCA tool?
It’s important to consider the following when looking at software composition analysis tools:
1. Technology Support: How universal is it and does it support all coding languages and package types used by your organization.
2. Ecosystem Integration: The SCA tool must integrate with repositories, IDEs, package managers, CI servers and more... via out-of-the-box integrations and via rich open APIs.
3. Database: A comprehensive license and vulnerability database is a must have to provide you the best coverage.
How are SCA tools different from other application security tools?
A full security stack should be comprised of the following tools:
- Dynamic Application Security Testing (DAST)
- Interactive Application Security Testing (IAST)
- Software Composition Analysis (SCA)
- Static Application Security Testing (SAST)
JFrog Xray is an SCA tool that focuses on detecting and eliminating open source security vulnerabilities and license compliance issues from the OSS components and dependencies you rely on to write your application code. With codebases being made up of up to 90% OSS, means Xray can have a huge impact on ensuring the stability and safety of your production releases.
Organizations that adopt such an approach see improvements throughout the SDLC, including these: improved quality through early identification of issues, visibility across proprietary and open-source code, lower remediation costs by detecting and fixing vulnerabilities early in the development process, minimized risk of security breaches, and optimized security testing
What are the risks of relying on free CVE/NVD databases?
You can have the best integration of SCA tools ever, but a security scanning solution is only as good as the database of vulnerabilities that drives it. Using a database that isn’t up-to-date with the latest vulnerabilities is like trying to find someone in a crowd without knowing what they look like. Some companies see the use of MITRE’s Common Vulnerability Enumeration (CVE) in the National Vulnerability Database (NVD) as the gold standard to secure against. Many security experts are adamant that relying on CVE and NVD for vulnerability data is not sufficient anymore.
For example, Risk Based Security, who are known for having one of the most timely and comprehensive vulnerability intelligence services available - VulnDB, have consistently eclipsed the total number of vulnerabilities identified and cataloged by the CVE and NVD each year. Over 249,155 vulnerabilities, covering products of 27,676 vendors, including tens of thousands of vulnerabilities not found in CVE/NVD, making VulnDB the most comprehensive solution on the market. Over 2,000 3rd Party Libraries have been identified and monitored for vulnerabilities.
JFrog Xray benefits from having a tight integration with VulnDB, it’s primary source for vulnerability and license compliance intelligence.
What are the benefits of using an external security database such as VulnDB?
First, many security experts in the industry are adamant that relying on CVE and NVD databases for vulnerability data is not sufficient anymore. It can take a long time before a vulnerability is published in the CVE/NVD databases and in the meantime bad actors can be analysing these vulnerabilities and figuring out how they can utilize them for nefarious activities.
The sooner that your SCA solution has a vulnerability in the database, the sooner you can secure your production code against having that vulnerability in it. The same is true of checking for license types and versions. Your compliance or legal departments will have a set of guidelines with regard to the use of open source software licenses. Having an up-to-date database of licenses to check against, enables you to minimize the risk of having unintended license types in your production code, which can be expensive and complicated to deal with.
Why do you need to check for license compliance?
Ensuring license compliance in OSS dependencies is a growing concern for compliance managers, legal teams and CEOs alike. No-one wants to be on the receiving end of a failed audit, or an expensive Intellectual Property or license infringement case. Knowing what OSS is being used, by which developers and in which builds and releases is of huge importance.
We are all painfully aware of the cost of security breaches. You only have to think back to the recent SolarWinds breach, or further back to the notorious Equifax fiasco, which cost them Billions. There is a huge risk of being out of compliance with software licenses, which can land you in a complex and expensive intellectual property battle. It is possible that the terms of certain licenses mean that if you use their code, you have to make your whole application code open source! And I don’t know many CEOs keen to give away their crown jewels for free. For some companies more than others because of the nature of the software you could be subject to audits of your software; and a failed audit can be subject to steep fines, depending on the industry you’re in.
Scan Your Images
Try out JFrog DevSecOps Tools now!
Run a FREE security scan fo your images!
