User account menu
Main navigation
As I reflect on the trio of technology industry events I’ve attended over the last few months, security stands out as the dominant theme across all three.
At KubeCon + CloudNativeCon (henceforth just KubeCon), which the Cloud Native Computing Foundation (CNCF) runs, the approximately 7,500 in-person attendees could walk up to dozens of security vendor booths, and that’s not even counting the security products and demos on display at the booths of larger multi-product vendors.
Many keynotes and breakouts at KubeCon – as was the case at All Things Open and the Linux Foundation Member Summit – touched on security to various degrees. For example, the KubeCon keynote by Ayse Kaya, Senior Director, Strategic Insights & Analytics, Slim.AI, in which she argued that the industry needs to do a better job of prioritizing the most serious security threats rather than always being “all hands on deck.” This sentiment appeared in various forms throughout the events.
Red Hat’s recently released 2023: Global Tech Outlook report also identified security as the top IT funding priority among the decision-makers surveyed.
Several aspects play out in both the broader software and market landscape as well as specifically in open source.
The overall environment has just become more threatening. Attackers are evolving.
“More and more popular packages are under attack,” says Jossef Harush Kadouri, head of software supply chain security at Checkmarx. For example, tricking users into visiting malicious websites with URLs that are common misspellings of legitimate websites is now commonplace enough to have its own name: typosquatting.
[ Also read Why security should be on every IT department’s end-of-year agenda. ]
Brian Fox, CTO of Sonatype, notes that “attacks increasingly attack developers and infrastructure,” and not just in the case of open source software. This is a particular problem given that the risk is consolidated in a relatively small number of maintainers and software that are particularly critical. Fox emphasized, however, that the problem is not so much that upstream software isn’t getting fixed but that 96 percent of the time, consumers are not downloading patched versions.
A large majority of the code in both internal and public-facing applications that businesses and others write is open source code, including all the dependencies many open source projects have on other open source projects: Think of this web of dependencies as a supply chain, but for software instead of manufactured parts – a software supply chain, in other words.
It’s this type of vulnerability that has led to some of the highest-profile software security flaws, such as the remote code execution vulnerability in Apache’s Log4j software library in late 2001. The U.S. Federal government (among others) has also sounded the alarm, publishing Enhancing the Security of the Software Supply Chain to Deliver a Secure Government Experience in September 2022.
Among the many security sessions at this fall’s events, talks related to software supply chains were probably the most common. With all this attention – and the many tools available to mitigate the issue – you might think this was at least on its way to being a largely solved problem.
It’s not. At least not yet.
Consider one data point from the aforementioned 2023: Global Tech Outlook report. While security was indeed the top IT funding priority, when we looked at the funding priorities within security, third-party or supply chain risk management came in at the very bottom – just as it did last year. Just 12 percent of survey respondents said it was a top priority. The report goes into some plausible reasons why this number may not be higher, but it’s hard to see it as an area of sufficient focus.
For another data point, Sonatype’s Fox observes that 38 percent of the world is still consuming vulnerable versions of Log4j. Patched versions were made available almost immediately after the vulnerability was discovered, but a huge amount of software has still not been patched.
In several conversations I had with security vendors and others at these events, there was a sense that, despite all the products already available, security approaches may have to fundamentally adapt. After all, as Albert Einstein (may have) once quipped, “The definition of insanity is doing the same thing over and over and expecting different results.”
More automation, coupled with machine learning, is probably part of the answer. We already see the management and control of complex distributed systems starting to be automated using AIOps.
One thing that has become clear is that shifting left to individual developers is not a satisfactory answer. Shifting tasks, checks, and remediations earlier in the process is good. But the right tooling needs to be in place.
That tooling needs to, among other things, provide the ability to track upstream dependencies and, just as importantly, what is currently deployed into production and elsewhere. Such systems are commonplace in manufacturing, such as the automotive industry, where serious supply chain issues make headlines and can cost lives. However, as the stats show, IT organizations need to be faster to recognize the importance of their software supply chains and apply rigor to fixing them.
To some degree, this is understandable. The heavy reliance on so much software from upstream open source communities – in addition to whatever proprietary libraries and other code – is a relatively recent phenomenon, and IT organizations can be forgiven for not having put supply chains at the top of their list of concerns. Be that as it may, the situation needs to change.
[ Discover how priorities are changing. Get the Harvard Business Review Analytic Services report: Maintaining momentum on digital transformation. ]
Keep up with the latest advice and insights from CIOs and IT leaders.
Privacy Statement
Keep up with the latest advice and insights from CIOs and IT leaders.
Privacy Statement
The Enterprisers Project is an online publication and community helping CIOs and IT leaders solve problems.
The opinions expressed on this website are those of each author, not of the author’s employer or of Red Hat. The Enterprisers Project aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Red Hat logo are trademarks of Red Hat, Inc., registered in the United States and other countries.
Follow us @4Enterprisers on Twitter
Like The Enterprisers Project on Facebook
Watch us at The Enterprisers Project
Connect with us on Linkedin
RSS Feed
Copyright ©2022 Red Hat, Inc.
Legal
source
—
Note that any programming tips and code writing requires some knowledge of computer programming. Please, be careful if you do not know what you are doing…