Securing the Kubernetes software supply chain

Modern software development practices make securing the software supply chain more important than ever. Our code has dependencies on open source libraries which have dependencies on other libraries and so on—a chain of code that we didn’t develop, didn’t compile, and have little or no idea where it came from.

Some of that code is almost ubiquitous. The Log4Shell exploit that caused havoc across the industry was from an exploit resulting from an old bug in a common Java logging component, log4j. We’re building an industry that stands not on the shoulders of giants, but on the shoulders of a handful of application and component maintainers who keep our global infrastructure working in their spare time and out of the goodness of their hearts.

Distributed development adds risks

This is not to minimize the work maintainers do; they’re an essential part of the modern software supply chain, delivering everything from small modules to entire container-based platforms. They’re undervalued and underpaid for how important their code is. Sadly, there have been several instances where bad actors have offered to take over maintaining code, only to add in malware, expecting the code to be installed automatically as it had a history of being trustworthy.

We can expect to see more attacks like these as more of our code becomes a group effort. How do we protect ourselves and our applications? First and foremost, we need to understand that the software supply chain does in fact exist, that we’re not building code in isolation, and we haven’t been doing so for a long time now, if we ever did. Open source and third-party libraries are an essential part of how we make software, and they’re only going to get more important.

What steps can we take to secure the software supply chain? A lot of work has gone into providing the tools to manage the software bill of materials: scanning code for libraries, using static and dynamic analysis, adding digital signatures and hashes to code, and bringing it all into managed repositories. But one part of the picture is missing: How do we validate that work and validate the code we’re using? After all, one of the age-old security adages remains “trust but verify.”

Securing the software supply chain

We need to trust the code we use, but we also need to verify that it’s trustworthy. We also need to do it under time pressure, with cloud-native code shipping new builds as code in repositories changes. The automated nature of modern development is key here, with platforms like GitHub at the heart of our software life cycle, delivering continuous integration and continuous delivery (CI/CD).

Copyright © 2021 IDG Communications, Inc.

Source link

Leave a Comment

Your email address will not be published. Required fields are marked *