Detecting threats and risks in containers before they are deployed is a critical step, but the size and complexity of containers — virtual, self-contained software applications — can grow as they are developed.
Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.
In addition, while vulnerability monitoring during any development is important, the rise of software supply chain attacks — and new threats coming from AI — makes additional security controls a new requirement.
Here are seven essential best practices to guide your development team on securing containers against today's threats to the software development lifecycle (SDLC).
[ Get White Paper: Close the Supply Chain Security Gap with Complex Binary Analysis ]
1. Start with a clean, minimized container image
To best secure and protect your containers, it is wise to begin with the cleanest minimized containers that you can create. The reason is simple: Clean, minimized images lets developers begin with more stable code that immediately reduces its attack surfaces, making them safer from cybercriminals from the start.
Once that stable code is used to create the container, the developer can then add needed, specific modules to the work, again keeping it minimized and straightforward by focusing on clean code while avoiding vulnerabilities that can accidentally be left behind.
By building with purpose, taking these first steps in container construction helps developers build a complete image that is more secure and more organized, said Dave Ferguson, director of technical product management at ReversingLabs.
“The way development teams create container images is they start with a base image where a lot of unnecessary stuff is stripped out of it, and that goes to reducing your attack surface. Starting with a minimized container image that is clean and does not have a lot of bloat, it is a key starting point before you add any of your own application code to the container.”
—Dave Ferguson
2. Start with early first scans to find and fix initial flaws
Once the clean container images are built, it's critical to scan them early on to detect all the things that can be wrong with the code. However, these early scans are not the end-all for the containers. Instead, they provide the foundation for the continuous process of code scanning. “We are looking for things when we're building in the early stage of a container construction that could cause a problem down the road,” Ferguson said.
Jasmine Noel, senior product marketing manager at ReversingLabs, said additional security scans are imperative as the container building process continues. That's because certain types of cyberattacks — malware, tampering and secrets exposure — are on the rise, and can only be found later as the containers approach deployment.
Noel said that these scanning steps become even more important as containers reach sizes up to 50GB, which requires additional scanning power and resources.
3. Control access for all container users
When building and finalizing the containers, teams must ensure that the container environment is secure against unauthorized access from outside users, including cybercriminals — and even former employees. That means auditing the lists of users who have access to the containers.
Ferguson said that security teams must ensure that they always know who is accessing the containers — while also monitoring the systems which provides that access using authorization controls, identification management, principles of least privilege, and other steps.
This needs to be done not just with containers, but also with the systems that manage and build the containers, including the continuous integration/continuous integration (CI/CD) systems to best protect the security and integrity of the container building tasks, Ferguson said.
4. Lock down container runtime environments
Ferguson said the first step is to minimize the attack surface.
“Slimming down a container image is probably the number one thing you can do to reduce your attack surfaces, because you don't want anything in your container that you don't actually need to run for your application."
—Dave Ferguson
But most importantly, when you are building containers — using Docker, Kubernetes, Red Hat OpenShift or other container environments — testing them during runtime is critical to to protect them from external threats, Ferguson said. An excellent resource to help with this: The Center for Internet Security (CIS)'s benchmarks, which are community-developed secure configuration recommendations that organizations can use to harden their software defenses and infrastructures.
Noel said all components should be tested before you deploy, so you get a complete picture of what you're going to be putting into your runtime before you run it.
“At that point you're mainly looking for something malicious that has been embedded in there – malware, or someone has tampered with something and it's behaving strangely. It's that sort of stuff that you want to catch just before you deploy.”
—Jasmine Noel
5. Use the best available software testing tools
Building the most secure containers starts with having the best available testing tools. Some tools check for vulnerabilities, while other tools will check for software license inclusion and validation, as well as for container misconfigurations. Others will provide a wide range of additional checks and tuning for containers and their eventual deployments.
While traditional tools — including static application security testing (SAST), dynamic application security testing (DAST) and software composition analysis (SCA) — can help with the baseline stuff, modern threats targeting the software supply chain and artificial intelligence (AI) require new controls such as complex binary analysis, which can scan compiled software package binaries before they are released, RL's Noel said.
Researchers from Wiz found multiple issues with free AI components on Hugging Face earlier this year, including one that gave attackers the ability to write to internal container registries. In February, JFrog reported finding as many as 100 ML models on Hugging Face with backdoors that could have enabled attackers to access the development environments of organizations using those models.
Anthony Tam, manager of security engineering at Tigera, said the risk from the open-source AI-development ecosystem was of particular concern. He said frameworks such as SAIF (Secure AI Framework) by Google, however, can help, by providing a good starting point for developers and those using open-source machine learning (ML) models in their development a solid understanding of how they can be best secured.
"Open-source AI has risks just as any open-source software has risks, by being community-driven and -developed."
—Anthony Tam
A number of new tools and approaches is also becoming available to help teams mitigate open-source AI risks.
6. Don’t forget the software bills of materials (SBOM)
Including a software bill of materials (SBOM) in with your container code is important so that users receive a list of all the known components that are in the applications that you build. But going beyond traditional SBOMs today is also a new requirement for dealing with threats.
Today there are bills of materials for machine learning (ML-BOMs), for AI (AI-BOMs), and for cryptographic requirements (CBOMs), RL's Ferguson said. But most important to making them actionable is to keep them up to date, he said.
“Ideally, you should be generating an SBOM as you are generating the container image so that way you have it every time you build it. You can have a history of how the container changes, including its components. Not everybody does this, but this is something you must use as a best practice."
—Dave Ferguson
Many SBOM requirements came from federal government initiatives that require SBOMs for federal software procurement. But the standard is extending beyond federal circles today. Growing awareness of SBOMs' usefulness have led to growing adoption of SBOMs. Gartner has predicted that 60% of organizations will require SBOMs from their vendors when procuring mission-critical software. The other 40% should do so as well.
“It is about software transparency. There have been so many security issues in the past because people are running software and they don't know what's in it.”
—Dave Ferguson
The best example of why transparency is essential: The Log4j vulnerability in 2021, which was found in the Apache Log4j logging library and allowed hackers to easily take control of devices that were running unpatched version of the code. When potential users later saw that Log4j was included in SBOMs for applications, they then knew not to use it if it had not been patched.
With AI rise, developers are including ML models in their in their software, making specialized ML-BOMs essential, Ferguson said. C-BOMs, used for securing cryptographic technology, are becoming more critical with the coming quantum computing advancing, Ferguson said.
7. Expand your security practice beyond vulnerabilities
While running security scans early and often throughout the container development lifecycle is essential, modern threats require expanding testing practices to suspicious files, malware, and the detection and presence of any sensitive data that is inadvertently included within the containers.
“Think beyond vulnerabilities. Look at malware injections, tampering, leaked secrets in the code, all these things. These are security issues you need to be aware of and are reviewing. They're not vulnerabilities, but these are huge security issues you need to also be protecting yourself from.”
—Dave Ferguson
Noel said that traditional AppSec testing for vulnerabilities when it came time to release the software was too late. “There is a certain group of attacks that you literally can only find at that point,” she said
“With those types of attacks, it's not just a vulnerability that you're fixing now. This is about finding if someone who has broken into your environment in one way or another and is now interfering with the thing that you're going to deploy and run.”
—Jasmine Noel
A secure SDLC — containers and all — is key
ReversingLabs’ director of product management, Charlie Jones, explained recently in an Open Source Security Foundation blog post that the attack surface within software supply chains has grown exponentially. Because of this, it has become even more difficult for organizations to manage risks that stem from open-source, proprietary, and commercial off-the-shelf software. To address these risks head on, Jones urges organizations to look beyond traditional application security technology to tactical binary analysis to properly secure their supply chains.
“Compromises such as those of VoIP provider 3CX highlight the gaps in software supply chain security — and the need for a new approach to supply chain risk management.”
—Charlie Jones
A secure software development process is key to preventing — or at least minimizing — the sorts of issues that could trigger legal exposure under the new rules like the EU's Product Liability Directive, said ReversingLabs chief trust officer Saša Zdjelar. He said organizations should make sure the process includes threat modeling for identifying threats during the design phase, industry-standard coding practices, code reviews, and testing using static and dynamic scans.
With the rapid adoption of containers — and the rise of AI-generated code — organizations need to go beyond traditional application securitypractices, and bolster their capabilities with advanced technologies such as complex binary analysis and reproducible builds, Zdjelar said.
Article Link: 7 container security best practices