From the course: DevSecOps: Building a Secure Continuous Delivery Pipeline

What's in your app?

From the course: DevSecOps: Building a Secure Continuous Delivery Pipeline

Start my 1-month free trial

What's in your app?

“

- [Narrator] The inherit stage is a tricky one as it's often not a stage of a CI/CD pipeline that many people really talk about. I refer to this as the invisible phase because this is where software dependencies get bundled into the application and inherited into our code. This is a real problem. In the 2018 DevSecOps Community Survey, 31% of respondents suspect or have verified a breach related to an open source component in the last 12 months. Many headline grabbing breaches within the last three years are related because many of them were due to inherited components. Outdated libraries, dependencies, frameworks, or even OS packages are often to blame. Sometimes it's easy to think of my app as just a couple hundred lines of code or LOC, it's simple right? But when we stack up all the libraries needed to run our application, add in the frameworks, and all of the server components, we arrive at our real LOC number, this is all the code that makes your application work. One way to understand exactly what your app is made of is to publish a BOM or a bill of materials. The BOM is a record of all the components, libraries, and dependencies you have. That same DevSecOps Community Survey mentioned earlier also found that only 38% of respondents had a software bill of materials which as a problem. This is just common sense. If a library is found to be vulnerable, you need to know if you're using it. By publishing a BOM, you have a quick reference for what libraries and versions are shipping with a particular application. At Signal Sciences, we are a go dev shop and we have a jenkins job that runs a daily BOM and reports back on the libraries we are rendering and how out of date each one is. This gets pumped into our slack channel for the engineering team to keep an eye on and it keeps creates a positive feedback loop. Now I know that not everyone is a go shop and these tools are very language specific. Some languages like Ruby have this as part of the culture with bundler and bundler audit, but in many languages this is less common. The goal here is to find a tool that you can put into your CI/CD pipeline that checks for dependencies that make you vulnerable. The tools themselves need to be up to date and have access to current Vul databases with the most recent Common Vulnerability Exposures or CVE's in them. Instead of doing goling examples, I'd like to look at two tools for other languages in the upcoming videos. First, we'll look at a popular job option, OWASP Dependency Check. And next we'll look at a javascript option called Retire.js. Both run in CI environments easily, so let's take them for a spin.

Contents