What is really your code versus the framework versus all the libraries you inherit? It is hard to really draw a clear line here, so let's talk about what is in our app and what we can do to secure the inherit phase.
- [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.
- Goals for a DevSecOps toolchain approach
- Development, inherit, build, deploy, and operation tools
- Keeping secrets with git-secrets
- Using OWASP Dependency Check
- Testing for dependency issues using Retire.js
- Options for software composition analysis
- Key security concerns for the deploy phase
- Tricks for making compliance happy
- Cloud configuration monitoring