Third-party software security is a hot topic. The SolarWinds breach made sure of that. This checklist is not exhaustive, but it offers four high-level best practices for securing third-party software, each with one or more technology solutions. Both commercial and open source solutions are included where available.
DEPENDENCIES: Verify all components are up-to-date, preferably using a dependency checker, or software composition analysis (SCA) tool, during build or compile time. This is likely not something a developer would ever do (or could do) by hand in a reliable manner. Leading solutions here include:
➢ Dependabot: This is a GitOps-based approach (see Page 3) for keeping software dependencies up to date. It is directly integrated into your software repo – GitHub in this case – and is free of charge.
➢ OWASP Dependency-Check: This is an open source SCA solution. It is free to use as well, although not pipeline/repo integrated. It provides CPE and CVE identifiers. The dependency checker updates itself from the National Vulnerability Database (NVD).
➢ Retire.JS: As the name suggests, this is a SCA solution for JavaScript. It’s also open source and can run:
• As a solution you integrate into your pipeline
• Locally via the command line
• In your browser
➢ Snyk: This is a commercial solution, but it also has an open source option that is free to use for individual developers. Snyk got its start with SCA, but has subsequently expanded to a whole host of developer-first solutions. It is this latter point where Snyk distinguishes itself among its commercial peers – its distinct focus on developers and their workflows.
➢ Black Duck: This was an early open source dependency checking (SCA) solution that was later purchased by Synopsis. If you are pursuing a GitOps approach to development, however, Black Duck might not be your first choice because it is an older generation solution not designed around GitOps workflows.
➢ WhiteSource: This is another commercial SCA solution that is competitive with Black Duck and Snyk. It has no free tier or open source offering.
HYGIENE: Verify all unnecessary libraries, features, documentation, samples and configurations are removed, such as sample applications, platform documentation, and default or example users. This type of hygiene can be a lot of manual effort, but it is key for eliminating unnecessary attack surface. Leading solutions here include:
➢ Distroless: Distroless container images contain only the application, its resources and language runtime dependencies – no operating system distribution. This approach creates a smaller attack surface, reduces compliance scope and results in a small, performant image.
➢ Secrets Detection: This is a standard software development lifecycle (SDLC) practice that should be GitOps-based, but I put it here because it also ties to garbage found in logs, i.e., comments found in code associated with waste that should be removed by developers. There are plenty of open source and commercial solutions, for example::
• TruffleHog: This is a very popular open source solution for finding secrets in repositories. There is a commercial company supporting it as well - Truffle Security.
• GitGuardian: This is a commercial offering with a generous free tier.
TRUSTED SOURCES: Verify third-party components/frameworks come from pre-defined, trusted and continually maintained source/repositories that are widely used by many applications. Leading solutions here include:
➢ Code-signing/trusted app stores: Developers must verify software is signed and comes from a trusted app store.
➢ Private Docker registry: This allows you to control what is/isn’t used.
➢ Secure repository management: This is a huge topic with a lot of options/vendors. It is tightly coupled with the dependency topic. A great example is JFrog and its product XRAY.
➢ Public cloud registries: Most public cloud providers have integrated container scanning into their own repositories:
POLICY AS CODE: Instead of relying solely on developers to follow a specific checklist of items (and hoping they do the right things), organizations can use policy as code to enforce. Policy as code can look at configurations and/or respond to output from security solutions and make decisions, such as firing off alerts, blocking software and infrastructure from getting deployed, or performing auto-remediation (on a limited basis). Leading solutions here include:
➢ Open Policy Agent (OPA): OPA is a popular open source project for defining policy as code. Policies, or rules, are written in an “domain-specific language” called rego.
➢ Semgrep: This one is a bit of a stretch to treat as purely policy as code, but it is an open rules-based approach for statically analyzing code. It comes with a large community of rules and users, and also with a commercial solution. Semgrep with OPA can further reduce the likelihood of insecure code making its way into production, particularly within a GitOps-optimized pipeline.
➢ Conftest: You can think of this as a simplifying wrapper around OPA. In short, it makes it easy to write configuration checks. It can apply to container specs, infrastructure as code, and frankly anything with a configuration you want to validate. Here is an example for containers.
GitOps Overview/Rationale GitOps is alternatively called operations by pull-request. It is workflow automation triggered on changes in your software repo (most often Git). Figure 1 shows an assessment workflow triggered by a pull request.
The idea is the developers just do their job, and policy as code and assessments run integrated within Git – called and processed via web hooks. All the capabilities in the checklist above can be integrated directly into Git as GitHub actions. In fact, numerous security solutions are available in the GitHub marketplace – and many are free to use.
Measuring Success If you are simply handing a checklist to developers, they likely will not use it. The pressure to get software shipped often overwhelms non-revenue-generating/manual efforts. This is why integrating security (easily and economically) directly into workflows is key.
How do you know if you are getting any better at controlling for software security risk over time? The simple answer is metrics. The burndown metric is the simplest way to gauge impact of control change. Burndown metrics use both simple visualizations and underlying data structures to measure capability efficiency over time. They can give you a sense of how you are progressing in terms of hitting burndown rate goals and scaling. The latter is demonstrated when volumes increase yet efficiency rates stay the same and/or improve. Figure 2 shows a standard burndown visualization.
It uses 52 weeks of data. This visualization show the overall average, the linear trend (as a curve), key performance indicator (KPI) target and the actual rates plotted. This same visual can be used to measure the elimination of vulnerable software dependencies, container image vulnerabilities, secrets elimination in code, etc.
Visualization Explained A snippet of the 52 weeks of data is shown below. Each week holds hit and miss events. Most security data for metrics boils down to hit and miss events over time. Literally, 90 percent of the basic metrics you will find useful follow this format.
A “hit” in this case is a fixed issue, i.e., something no longer showing up in scans or other telemetry. A miss is something discovered in that week that was not fixed at that time. If it gets fixed at a later date, it would then be considered a “hit” in that week.
