When hidden Java packages put your company at risk

The global software supply chain is complex and full of risk. The average software package has over 40 dependencies, which can be easily forgotten or inadvertently introduced during integration. It is important to maintain visibility into these hidden dependencies by using an SBOM (Software Bill of Materials) to understand what you are installing on your systems and prevent malicious activity from taking place.

What is a software bill of materials (SBOM)?

If you’ve ever taken a peek inside your computer’s software, you’ll know that there are lots of pieces. Some are obvious, like the operating system. Others may not be as visible to users but still important, like libraries and frameworks.

When it comes to software security risk management, having a complete list of all the components your organization uses is essential to understanding the full set of risks associated with each one and how they should be managed. This information can help organizations prioritize their testing and remediation activities so that they focus on known vulnerabilities in the most critical components first.

The problem with the hidden Java dependencies

SBOM is a list of all the software on your device. This sounds self-explanatory, but it’s not quite as simple as it sounds. SBOM is not just about the software you write; it can include any third-party packages that are used by your application. These dependencies can be added to SBOM when they’re installed via an app store or even manually downloaded by you as part of an update process.

That’s right: if someone else has written code and installed it on their device, then whatever they’ve done will show up in your SBOM details. If they’ve made security-sensitive changes to those components (like modifying default settings), then those changes will be visible too!

In fact, this happens more than most people realize because developers often don’t realize there are hidden dependencies until after something bad has happened—and by then it may be too late for them to change anything about those dependencies without breaking their own apps

Why should you be concerned?

You should be concerned about hidden Java dependencies because they can be used to attack your network, other networks or even the cloud.

For example, in one case we investigated a malicious client-side application that was installed on users’ computers and then used to attack other systems via the internet. It did this using a hidden Java dependency that was loaded into memory when users visited particular websites.

Another example is an attack on multiple organizations where malware was spread through social engineering techniques and then used to download additional malware from servers hosted in foreign countries. The malware installed by these servers would infect machines running JVMs with hidden dependencies which would then connect back out to an IRC channel where commands were sent from infected machines back into their networks.

Due to the nature of Java applications, and the fact that it is impossible to know the state of the application in isolation, it is especially important to have a solution that provides effective SBOM at-rest and at-runtime. TrueSBOM can be easily integrated into applications to provide SBOM at-rest and at-runtime that are true and always up to date. No matter if you are a developer or using Open Source applications—you should be sure what dependencies are currently active, without the need to track every application and version independently.

How to anticipate, discover and monitor hidden Java dependencies

Many applications have inadvertently created hidden “secret” Java packages that compile and run but never get published. They are left behind after an initial test or development phase and are rarely subject to regression testing. This can put the entire application at risk when a new version needs to be tested, or a patch needs to be applied.

In order to make sure that your company is protected from hidden dependencies, you should:

• Use a tool to scan for hidden dependencies. There are several tools out there that can help you find and monitor for new hidden dependencies. If you don’t already have one in place, it’s a good idea to start using one now.
• Scan your codebase for hidden dependencies. It’s also important to make sure that you’re working with a team who understands how these malicious packages work—and what they can do if left unchecked—so all developers on the team know what they need to look out for when scanning their codebases (even those not responsible for building or packaging). This is especially important if some of the people on your team use different tools than others; ensuring consistency between them will help ensure everything gets caught before it makes its way into production code at any level of the build process.
• Scan your build process for hidden dependencies. As mentioned above, this will help prevent any malicious packages from getting into production builds by catching them early on in development instead of relying on manual reviews alone; if no one else has reviewed something before me then maybe there could be something wrong with it?

Build a more accurate SBOM and get control over your supply chain.

Build a more accurate SBOM and get control over your supply chain.

• Build an accurate SBOM. The Software Bill of Materials (SBOM) is a cornerstone of software security planning, but its accuracy can be compromised by hidden dependencies and undocumented modules.
• Monitor your SBOM. You can use the same hidden dependencies report I’ve mentioned to monitor for changes in the SBOM, but also keep tabs on any newly discovered dependencies as they’re discovered in other parts of your organization.
• Discover hidden dependencies in your SBOM. In some cases, you’ll find that certain components are being double counted or counted multiple times because they have different aliases or namespaces within the same package; this kind of discovery will help you get more granular with tracking down where vulnerabilities might exist by allowing you to break apart larger packages into smaller ones so that each component has its own proper identity

SBOM is a specification that can be used to implement capabilities in systems and applications. TrueSBOM enables you to verify whether your application contains sensitive data, but also to track what additional dependencies are currently active.

Conclusion

Java is just one example of a hidden dependency, but it’s important to know that this is not just a problem for Java developers. If you have any software in your organization that relies on Java, you need to be aware of the risks associated with hidden dependencies. You can take steps today to mitigate the impact of these vulnerabilities on your supply chain and protect yourself from security threats.

Implementing a TrueSBOM helps you to secure your systems at every level, as well as your Open Source applications. To ensure that you are always up-to-date with the latest security updates, TrueSBOM can be integrated into your applications and deployed into production within minutes.