Packages and Dependencies
Hallucination and Direct Malicious Code
There are 2 stories today that bring some great attention to the nature of dependencies and how code packages we build on top of them are both not owned by our organizations and sometimes by no one. Additionally, seeing the use of AI to provide packages that simply don’t exist. This is less malicious at this time but points to a cybersecurity concern that is new to the AI age. So, what lessons can we gleam from these current events? Let’s crack in.
Headlines
Know your dependencies
We have seen many times before where some packages that underlies large sections of the internet are changed in some way and cause impact across the internet. The reporting by Advocatmack (all props for the nice dive and link to the details) shows how something that underlies something else becomes compromised and we are left to deal with the fallout. XRPL is a blockchain for business according to their own site. Now a package being affected that underlies the source code can bring the whole of the product into question. Without more information we will not know if this is actively exploited or was added to the source code with malicious intent.
So do you know your organization’s dependencies. What is the source code that underlies your code base? This type of inventory, if it exists, is something that is likely to fall out of date as soon as we have it complete. One of the key factors is that developers are looking to move forward as quickly as possible, and cybersecurity tends not to be the first concern. This alignment of motivation creates issues between the CISO and the development team. However, when we put our organization on top of public code bases, we face the potential for our products or systems to be affected without any action on our part. Developers want to move quickly, and new packages can provide a way to move the whole of a project forward with little to no effort from the organization. The temptation is real and even needed for more complex solutions.
The lesson we can take is that we need to be involved in internal development and with the acquisition of new packages to ensure they are secure code bases to work from. Doing this is something far from easy to do. What we usually rely on is a SDLC that covers the usage of new packages or implementation into development. This is a larger topic than we can cover here but this is nearly an entire domain in the CISSP and so we will cover this there.
Secure Coding in the AI Age
The second article here covers the new issue of ‘slopsquatting’. This article is really worth a read as this is an entirely new topic. If a hallucination of a package can then be made real and infected creates a really interesting issue. However, the lesson here is the same for cybersecurity professionals. We must gain reigns over the development process at the beginning of any feature or product development. When we are there the c.s. professionals can provide insight and review to prevent the inclusion of unwanted or unreliable packages.