Container Scanning: How Thinking Outside the Box Can Keep You Safe, Part 2

Learn how a shift-left approach can help you mitigate risk from open-source technology.

*Header image credit: Devopedia https://devopedia.org/shift-left

In this two-part series, we explain why container scanning is a critical part of cyber security for web developers. Here, we advocate establishing a “shift-left” mindset in which developers are in the habit of scanning containers earlier and more often. Missed Part 1 about container scanning? Read it here.


We all know there is no such thing as perfect code. Any software ever written is destined to have vulnerabilities and weaknesses—aka Common Vulnerabilities and Exposures or CVEs. CVEs can leave you and your organization exposed and vulnerable to attacks by hackers and malicious actors. 

Of course, developers do all they can to reduce that risk, ideally with a comprehensive cyber risk management program that includes an ongoing assessment program. 

Unfortunately, no one governs the open-source community. That means every time developers freely pull software components off public websites, they are introducing new vulnerabilities and weaknesses, or even malware, to their applications.

So container scanning is critical. And it does not end with the first procedure. Consider: A container’s lifecycle is limited by versioning. A typical organization will adopt or follow agile methodologies, such as two-week sprints. But containers live for only a week or two before developers have a new version to deploy. So the two-week cadence leaves them vulnerable. 

How often should developers scan their containers? As frequently as possible. Vulnerabilities can develop at any time, and they should protect their application at all costs.

How and When to Scan 

A scan begins with a review of a container’s software composition (its file structure) and checking its dependencies for any known open-source components and then checking those components for known vulnerabilities. 

Most container scanning tools are implemented during the development cycle so developers can review any security concerns as they build their applications. Alternatively, they can be scanned once they are pushed to a Container Registry, when Security and Operations teams can scan their built applications before they are deployed into their production environment.

The tools look at different types of Linux OS Distribution packages (Alpine, RHEL, CentOS, Debian, etc.) and language-specific packages (Bundler, Go, npm, yarn, etc.). 


A Shift-Left Container-Scanning Mindset

Despite a number of highly visible cybercrime cases in the last few years, cyber security is not typically a priority for small- and medium-businesses. And container scanning in particular is anything but top of mind for most developers.

It’s time to think outside the box. Don’t treat container scanning as an afterthought. Instead, develop an automatic, “shift left” mindset, considering it to be a regular, and frequent, part of the innovation process. Scan early and often—both as the application is being built and once it is in use.

Download Trava's Complete Guide to Vulnerability Scan Types for a more detailed exploration of vulnerability scans for both internal and external environments, including:

Download the eBook

Recent Posts from the Trava Team: