What is the difference between an SCA scan and a container scan?

Are Software composition analysis (SCA) scans and container scans the same thing? The short answer is yes… and no. A comprehensive container image scan applies SCA specifically to containers in combination with other analyses particular to containers, such as how they’re configured to deploy and the presence of secrets. Read on to learn the key differences.

How does an SCA scan work?

SCA tools start with a scan to get an inventory of all open source components in whatever it’s set to scan, whether that be a single file or an entire repository. A container image SCA scan is no different—however, SCA scans designed to work with containers are usually configured to scan at each layer, keeping track of which components are in which layer as it goes. Once that list is compiled, the SCA tool gathers information about each component, such as which open source license it uses, which vulnerabilities have been reported for it, and the severity and exploitability scores for each vulnerability. 

Why scan containers for vulnerabilities?

As with most modern applications, the majority of the code that makes up images tends to be open source. Containers magnify the benefits of open source code, allowing organizations to build large, complex, and unique applications faster than ever. 

But containers also add another layer of complexity to an already complicated landscape, and that complexity can increase risk and lead to missed vulnerabilities. A container image scan will provide a list of all known vulnerabilities within the code, and a good scanning tool will help security teams prioritize those vulnerabilities based on exploitability and severity.

One good reason to scan container images for vulnerabilities regularly is that containers are designed to reuse code. This is part of what makes them so lightweight, but it can also lead to outdated and unpatched components within a container image.

Finding vulnerabilities that create security risks is the top concern of most organizations scanning their container.  However, “byproducts” of container image scans, namely open source license information and the creation of SBOMs, are often of interest to legal and compliance departments, too.

Beyond open source: the benefits of a container scan

A comprehensive container scanning tool won’t stop at open source components and their vulnerabilities. It will also scan files looking for secrets that have been placed in insecure locations. Secrets are sensitive credentials like passwords, keys, and tokens that would be extremely hazardous in the hands of an attacker. It’s a very high-risk security issue if developers have left them hard-coded in plaintext in source code or configuration files, something that, unfortunately, can happen easily in a rapid development environment.

In addition to secrets, a container scanning tool will look at infrastructure as code (IaC) files for misconfigurations that make the container vulnerable to attack. Misconfigurations are small (in the sense of the amount of code) mistakes that are typically easy to correct but neglecting to identify – something that can be easily done across a large codebase – and correct them can put the application at huge risk.

Scanning container images for vulnerabilities

Most available tools make scanning a straightforward process, whether you start a scan manually in the command line or set up automated scanning as part of a CI/CD pipeline. 

Container image scanning can be set to run at build to find open source vulnerabilities and mismanaged secrets before they enter the codebase, causing the build to fail if policies you set in place are violated. 

Container images can also be scanned at scale at the private registry level to get a larger picture of your security risk posture and prioritize remediation of the highest-risk containers. Containers can also be scanned as Kubernetes clusters so you can prioritize the containers currently used in production.

The process will be different depending on which tool you have, but here’s how to scan container images with Mend SCA, either via the command line or UI.

What is container runtime scanning?

Different people may mean different things when they say “container runtime scanning”. For our purposes we are not talking about tools that monitor running containers for signs of intrusion, but rather to using container image scanning tools to scan container images that are already actively used in production. 

These scans are the same as those mentioned earlier, except the scanning tool interfaces with Kubernetes to see which images in the scanned repository are running currently as containers in a K8 cluster. This helps teams prioritize fixes, as a container that isn’t running may have plenty of vulnerabilities but they are not exploitable at present. 

In addition to containing open source vulnerabilities, container images can have configurations that drift over time, meaning they are not the same in the running application environment as they are defined in the IaC files due to untracked changes from humans, applications making undesired changes, or changes not carrying over from environment to environment due to misconfigurations. Doing container scans at runtime can detect common causes of configuration drift.

Conclusion

SCA scans and container scans have a similar scope and similar capabilities, but container scans add container-specific features like scanning each layer separately, secrets detection, and misconfiguration detection.