Generative Data Intelligence

Cyber Security

Kubernetes and the Software Supply Chain

Republished by Plato
Republished by Plato

Date:

Views: 87

The ability of organizations to gain value from Kubernetes — and, more broadly, cloud-native technology — is being hampered by concerns around security. One of the biggest concerns reflects one of the industry’s biggest current challenges: securing the software supply chain. 

Red Hat’s “2023 State of Kubernetes Report” found that Kubernetes security is in question at some companies. Based on a survey of DevOps, engineering, and security professionals from around the globe, the report finds that 67% of respondents have delayed or slowed deployment due to Kubernetes security concerns, 37% have experienced revenue or customer loss due to a container/Kubernetes security incident, and 38% cite security as a top concern with container and Kubernetes strategies.

The software supply chain has increasingly come under fire, and Kubernetes shops are feeling the heat. When asked which specific software supply chain security issues they were most concerned with, respondents to the Red Hat survey noted:

  • Vulnerable application components (32%)
  • Insufficient access controls (30%)
  • Lack of software bills of materials (SBOM) or provenance (29%)
  • Lack of automation (29%)
  • Lack of auditability (28%)
  • Insecure container images (27%)
  • Inconsistent policy enforcement (24%)
  • CI/CD pipeline weaknesses (19%)
  • Insecure IaC templates (19%)
  • Version control weaknesses (17%)

These concerns seem well-founded among respondents, with more than half noting that they have first-hand experience with nearly all of them — especially vulnerable application components and CI/CD pipeline weaknesses.

There is a great deal of overlap among these issues, but organizations can minimize concerns about all of them by focusing on one thing: trusted content.

The ability to trust content is getting increasingly challenging as more and more organizations use open source code for cloud-native development. More than two-thirds of application code is inherited from open source dependencies, and trusting that code is key to tightening application and platform security, and, by extension, gaining the most value from the container orchestration platform. 

Indeed, organizations cannot create trusted products and services unless/until they can trust the code used to build them. Software bills of materials are designed to help ensure the provenance of code, but they should not be used in isolation. Rather, SBOMs should be considered as part of a multipronged strategy to secure the software supply chain, with trusted content at the core.

No SBOM Is an Island

SBOMs provide the information developers need to make informed decisions about the components they’re leveraging. This is especially important as developers pull from multiple open source repositories and libraries to build applications. However, the very existence of an SBOM does not ensure integrity. For one thing, an SBOM is only as beneficial as it is up to date and verifiable. For another, listing all the components of a piece of software is only the first step. Once you know the components, you need to determine whether there are known issues for those components.

Developers need upfront quality and security information about the software components they are selecting. Software providers and consumers alike should be focusing on curated builds and hardened open source libraries that have been verified and attested with provenance checks. Digital signature technology plays an important role in ensuring that a software artifact has not been altered in any way while in transit from the public repository to the end user’s environment.

Of course, even with all of this in place, vulnerabilities happen. And, given the large numbers of vulnerabilities identified throughout the set of software developers rely on, additional information is needed to help teams assess the actual impact of a known vulnerability.

VEX-ing Issues

Some issues have a greater impact than others. That’s where VEX — or Vulnerability Exploitability eXchange — comes in. Via a machine-readable VEX document, software providers can report the exploitability of vulnerabilities found within dependencies of their products — optimally, using proactive and automated vulnerability analysis and notification systems. 

Note that VEX goes beyond providing vulnerability data and status; it also includes exploitability information. VEX helps to answer the question: Has this vulnerability been actively exploited? This enables customers to prioritize and effectively manage remediation. Something like Log4j would warrant immediate action, for example, whereas a vulnerability without a known exploit might wait. Additional prioritization decisions can be made based on determining whether a package is present but not used or exposed.

Attestation: The Third Leg of the Stool

In addition to SBOMs and VEX documentation, package attestation is required to engender trust in content.

You need to know that the code you’re using is developed, curated, and built with security principles in mind, and delivered with the metadata you need to verify provenance and content. When both SBOMs and VEX documents are provided, you have a way to map known vulnerabilities to software components in the package you are evaluating, without the need to run a vulnerability scanner. When digital signatures are used for attestation of packages and associated metadata, you have a way to verify that content has not been tampered with in transit.

Conclusion

The standards, tools, and best practices mentioned align with (and complement) the DevSecOps model, and will go a long way toward alleviating the security concerns that go hand in hand with the rapid pace of deployment that Kubernetes enables.

spot_img

Latest Intelligence

spot_img

Copyright @ 2024 Plato Technologies Inc.

Chat with us

Hi there! How can I help you?