The power of organizations to realize worth from Kubernetes — and, extra broadly, cloud-native know-how — is being hampered by considerations round safety. One of many largest considerations displays one of many business’s largest present challenges: securing the software program provide chain.
Pink Hat’s “2023 State of Kubernetes Report” discovered that Kubernetes safety is in query at some firms. Based mostly on a survey of DevOps, engineering, and safety professionals from across the globe, the report finds that 67% of respondents have delayed or slowed deployment attributable to Kubernetes safety considerations, 37% have skilled income or buyer loss attributable to a container/Kubernetes safety incident, and 38% cite safety as a prime concern with container and Kubernetes methods.
The software program provide chain has more and more come beneath hearth, and Kubernetes retailers are feeling the warmth. When requested which particular software program provide chain safety points they had been most involved with, respondents to the Pink Hat survey famous:
- Susceptible utility parts (32%)
- Inadequate entry controls (30%)
- Lack of software program payments of supplies (SBOM) or provenance (29%)
- Lack of automation (29%)
- Lack of auditability (28%)
- Insecure container photographs (27%)
- Inconsistent coverage enforcement (24%)
- CI/CD pipeline weaknesses (19%)
- Insecure IaC templates (19%)
- Model management weaknesses (17%)
These considerations appear well-founded amongst respondents, with greater than half noting that they’ve first-hand expertise with almost all of them — particularly weak utility parts and CI/CD pipeline weaknesses.
There may be quite a lot of overlap amongst these points, however organizations can reduce considerations about all of them by specializing in one factor: trusted content material.
The power to belief content material is getting more and more difficult as increasingly organizations use open supply code for cloud-native improvement. Greater than two-thirds of utility code is inherited from open supply dependencies, and trusting that code is vital to tightening utility and platform safety, and, by extension, gaining essentially the most worth from the container orchestration platform.
Certainly, organizations can’t create trusted services and products until/till they will belief the code used to construct them. Software program payments of supplies are designed to assist make sure the provenance of code, however they shouldn’t be utilized in isolation. Reasonably, SBOMs needs to be thought-about as a part of a multipronged technique to safe the software program provide chain, with trusted content material on the core.
No SBOM Is an Island
SBOMs present the data builders must make knowledgeable selections concerning the parts they’re leveraging. That is particularly necessary as builders pull from a number of open supply repositories and libraries to construct purposes. Nevertheless, the very existence of an SBOM doesn’t guarantee integrity. For one factor, an SBOM is simply as helpful as it’s updated and verifiable. For an additional, itemizing all of the parts of a chunk of software program is simply step one. As soon as you understand the parts, you must decide whether or not there are identified points for these parts.
Builders want upfront high quality and safety details about the software program parts they’re deciding on. Software program suppliers and shoppers alike needs to be specializing in curated builds and hardened open supply libraries which have been verified and attested with provenance checks. Digital signature know-how performs an necessary position in making certain {that a} software program artifact has not been altered in any manner whereas in transit from the general public repository to the tip person’s atmosphere.
In fact, even with all of this in place, vulnerabilities occur. And, given the big numbers of vulnerabilities recognized all through the set of software program builders depend on, further info is required to assist groups assess the precise influence of a identified vulnerability.
VEX-ing Points
Some points have a larger influence than others. That is the place VEX — or Vulnerability Exploitability eXchange — is available in. Through a machine-readable VEX doc, software program suppliers can report the exploitability of vulnerabilities discovered inside dependencies of their merchandise — optimally, utilizing proactive and automatic vulnerability evaluation and notification methods.
Notice that VEX goes past offering vulnerability information and standing; it additionally contains exploitability info. VEX helps to reply the query: Has this vulnerability been actively exploited? This permits prospects to prioritize and successfully handle remediation. One thing like Log4j would warrant instant motion, for instance, whereas a vulnerability with out a identified exploit may wait. Further prioritization selections might be made based mostly on figuring out whether or not a package deal is current however not used or uncovered.
Attestation: The Third Leg of the Stool
Along with SBOMs and VEX documentation, package deal attestation is required to engender belief in content material.
That you must know that the code you are utilizing is developed, curated, and constructed with safety rules in thoughts, and delivered with the metadata you must confirm provenance and content material. When each SBOMs and VEX paperwork are supplied, you might have a strategy to map identified vulnerabilities to software program parts within the package deal you might be evaluating, with out the necessity to run a vulnerability scanner. When digital signatures are used for attestation of packages and related metadata, you might have a strategy to confirm that content material has not been tampered with in transit.
Conclusion
The requirements, instruments, and greatest practices talked about align with (and complement) the DevSecOps mannequin, and can go a good distance towards assuaging the safety considerations that go hand in hand with the speedy tempo of deployment that Kubernetes allows.