“AppThreat started with the simple mission to make high-quality code analysis and security tools for everyone,” says Prabhu Subramanian, lead maintainer of atom and chen, founder of AppThreat, and creator of other open source supply chain security tools like OWASP CycloneDX Generator (cdxgen), OWASP blint, and OWASP depscan.

While working on a different problem, Prabhu uncovered a lack of high-quality code hierarchy analysis libraries and CLI tools. atom and chen were built as open source tools to identify likely adversary entry points to improve threat modeling, vulnerability management, and risk mitigation. Precisely knowing when, where, and how a given library is used in an application or service empowers developers to better understand risks and secure their work.

chen, or Code Hierarchy Exploration Net, is an advanced exploration toolkit for your application source code analysis to parse and extract code property graphs.

Powered by the chen library, atom is a novel intermediate representation for applications and a standalone tool. The intermediate representation (a network with nodes and links) is optimized for operations typically used for application analytics and machine learning, including slicing and vectoring.

“As our projects grew in usage and significance, we felt the need to donate these projects to an open source organization committed to the original AppThreat mission,” says Prabhu. “AboutCode is that organization.” 

AboutCode is a registered non-profit organization that supports the development and maintenance of the AboutCode stack of open source tools and open data for SCA, including the industry-leading ScanCode, VulnerableCode, and DejaCode projects. AboutCode believes that good open source tools and open data help you use open source securely and efficiently.

With planned tighter integrations with the AboutCode stack, atom and chen will provide an even more comprehensive open source solution for the practical management of open source and security compliance. This includes advanced code reachability analysis, more efficient triage of vulnerabilities based on true reachability, and deep analysis of call graphs to find where vulnerable code is used.

For supply chain analysis, atom can generate evidence of external library usage, including the flow of data. OWASP cdxgen uses atom to improve the precision and comprehensiveness of the generated CycloneDX SBOM document. 

For vulnerability analysis, atom describes vulnerabilities with evidence of affected symbols, call paths, and data flows to enable variant and reachability analysis at scale.

“The next frontier in vulnerability management is deep vulnerable code reachability analysis and taint analysis to discover new vulnerabilities,” says AboutCode lead maintainer Philippe Ombredanne. “atom and chen are the fundamental blocks to enable the construction of a FOSS solution to better triage vulnerabilities and avoid vulnerability fatigue.”

Building upon atom and chen joining, AboutCode will adopt an open governance model, drawing from best practices established by other organizations committed to open source software, prioritizing transparency, inclusivity, and community-driven development. A technical advisory group (TAG) will be formed to ensure project development addresses the needs of the wider community.

Want to get involved? Join the AboutCode Slack and Gitter to chat with the community.

Development of Python-inspector grew out of a need to resolve dependencies on demand and anywhere. pip (unfortunately) does not support resolving dependencies without installing or building them. These installations and the underlying dependency resolutions are only for the current Python version and runtime used to run pip, and that may not be the target version or OS we need to resolve the dependencies.

Watch the recorded video from PyDelhi 2023 with Tushar Goel to learn how to use Python-inspector in your own projects and more easily resolve Python dependencies. 

In DejaCode, you can define and enforce usage policies at license and component levels across teams, with the ability to customize those policies based on your organization’s needs and legal requirements.

Watch this recorded webinar with Product Manager Dennis Clark for a deep dive into how usage policies work in DejaCode and best practices to ensure open source compliance across your organization.

Many tools for Software Composition Analysis provide a wide range of capabilities. Basically, these capabilities include of detecting and reporting components, their licensing, vulnerability, and quality information. There are many specialized different techniques and tools for different development-side languages and frameworks. And there are more for specialized deployment-side platforms like containers or embedded systems.

But a key issue is that expensive proprietary SCA tools can be a huge inhibitor for people to do the right thing and manage the composition of their software. So to make using open source easier for everyone, we need FOSS tools for FOSS SCA.

In this webinar, nexB co-founder and CEO Michael Herzog discusses best practices for securing open source software supply chains by using open source Software Composition Analysis tools. With FOSS SCA tools, organizations don’t need to worry about vendor lock-in. And by sharing tools with upstream projects, organizations can improve the vitality of the overall FOSS community.

Vanity licenses exist. Obscure licenses exist. We may laugh or argue about why they were published, But how do we handle these license exceptions? If we don’t acknowledge and deal with all the licenses that exist in published software, we will keep having license exception headaches.

Many software license detection tools have two key problems:

• A too-narrow focus on the subset of common open source licenses while ignoring the high volume of less common licenses (the long tail) that exist in the real world.
• Exclusion of proprietary or commercial licenses that intersect or overlap with open source licenses, such as “dual” licenses.

For OSPOs to work with real data – not just theoretical assumptions – we need FOSS license detection tools that cast a wide net to handle all open source licenses, and future versions too. And we need FOSS tools to efficiently review these licenses and apply license policies across product codebases, updates, and versions.

The goal: Identify all licenses fast in a clean process with minimal license detection exceptions and by using FOSS tools and setting clear policies, OSPOs can empower organizations to quickly identify licenses and apply policies without asking developers to read license texts.

The result: Triaging license exceptions is easy.

Watch this recorded webinar with nexB co-founder and CTO Phillipe Ombredanne to learn more about how to quickly Identify all licenses in a standard process with minimal license detection exceptions.

FOSS Daily is a simple concept: Pay attention to your software – especially your open source components – as a daily habit, rather than on a retrospective cycle like every month, every quarter, or every release. It doesn’t take a lot of time, and you can probably skip a day or two, but long-term neglect can build up into expensive and painful procedures – both technological and dental. FOSS Daily is about small-scale prevention, instead of large-scale remediation.

Software development is always a continuous process. Code is constantly changing in general and the rate of change in dependencies continues to accelerate. Unfortunately, many organizations treat managing open source software as an afterthought, or just a compliance check before releasing and updating code. Without regularly monitoring FOSS components, an organization cannot accurately track the FOSS it is using. You will not have a good understanding of what you’re doing with open source if you don’t make managing it a part of your daily routine.

Developers often look up examples when writing code. There’s a long tradition of developers going to Stack Overflow and similar websites or repositories for code samples. In our experience with software audits, we often find cases where a developer provides a Stack Overflow or similar link to document borrowed code, but rarely do we find any attention paid to what the license of that code might be. This results in code that’s either unlicensed or under an unattractive license (for license compliance).

The default license for Stack Overflow is Creative Commons Attribution-ShareAlike 4.0 International Public License or CC-by-SA 4.0 (earlier versions of CC-by-SA apply to content shared on Stack Overflow at different dates), which is a Copyleft license. Stack Overflow actually tried to change their default to a more permissive license, but that change was blocked by their community.

This is why you need daily attention to the provenance and licensing of open source code. Developers need to get in the daily habit of checking the license for any code snippet before using it in any way. And organizations need to support developers by defining policies for when a snippet is material (e.g., number of lines which may vary by language) and which licenses are acceptable for using a code snippet in otherwise proprietary code. 

This example isn’t meant to scare any developers from using Stack Overflow for inspiration and information – we use it regularly too! The important clarification is that when a developer finds a code snippet with a focus on functionality, they also need to take the relatively small extra step to verify that it is offered under a license acceptable to their organization. If software doesn’t have a license, it’s unlicensed – there is no generic permission.

Organizations that are more attuned to compliance may even prevent the release of products or updates in this situation. Companies are now required to attest to the licensing of their software, typically with a Software Bill of Materials (SBOM). This means a much bigger risk for companies that do not track the provenance and licensing for each FOSS component (or snippet) with continuous daily attention.

Another key area of FOSS compliance that requires daily attention is the identification and mitigation of software vulnerabilities. Hundreds of new vulnerabilities are reported every day and there are also daily updates for vulnerability fixes. Daily triage of vulnerabilities is a key strategy to avoid being overwhelmed by the volume of new vulnerabilities over time. 

Compliance is a continuous process – not a periodic or cyclical process with certain time boundaries – embedding your tooling and policies into your workflows. There will be a steady flow of issues coming up. But that is just something to consider as part of software development and Ci/CD processes. FOSS Daily means that those issues don’t pile up and cause other issues that might block the release of a new software product or product version.

To get started with a FOSS Daily practice, first define your policies: What are your risk management policies for approving a software license and for mitigating software vulnerabilities? What tools do you use? Extending the dental analogy, you can use any kind of floss with good results so long as you pick one that works for your organization and risk management policies.

You have to be able to very quickly identify exceptions to your policy, so that most things can flow through quickly. For an exception you need tools to identify the type of exception, its severity and who is responsible for addressing it.

AboutCode Software Composition Analysis (SCA) tools are modular so that they can be embedded at various points in software development and CI/CD workflows. The key is to efficiently identify changes and exceptions that require your attention. Shifting this left in your workflow helps address potential issues on a daily continuous basis.

When you are writing code, there are linters and other tools to check the syntax of your code, but license information will be in comments or text files, not code. The DeltaCode module of ScanCode Toolkit efficiently scans for changes in licensing information as a complement to other code quality tools. This enables quick identification of any license changes to address them immediately.

For vulnerabilities, you want to track new vulnerabilities that affect your code and also track changes in the status of any vulnerabilities you have already identified. With VulnerableCode, you can automate the reporting for the packages you use and care about and ignore the noise from packages you do not use. And you can see the history of each vulnerability across data sources and time.

We know from psychology that once you adopt a good habit, it becomes a seamless part of your routine. But if you postpone or procrastinate, problems become worse and harder to resolve. 

With the analogy of flossing your teeth daily, nobody wants to go to the dentist for a root canal. The good habit of daily preventive activities helps avoid potential future pain.

The principles behind FOSS Daily are simple. Define your policies. Figure out how to automatically implement those policies and focus daily attention on the exceptions. Run the process every time you make changes with a clear process for exception handling. Deal with those exceptions in a timely manner because they can stack up quickly and develop into much bigger problems than when handled individually.

Daily attention to licensing “hygiene” prevents bigger problems later. It is much easier to ask for help with a small problem or send a specific question, than to wait for all these issues to accumulate and try to resolve them en masse, often at a critical and time-sensitive point in the software development cycle. FOSS Daily is a good habit to support FOSS licensing and vulnerability compliance for your organization.

If you’re using or building applications, you need tools to determine if there are any known security issues with open source and third-party components. 

If you’re building tools for Software Composition Analysis (SCA) like analyzing the origin, license, security, and quality of the code across different ecosystems. You need a simple way to identify the packages used.

Package URL (PURL) is a new open source standard to convey accurate identifications of the third-party software packages that were used.

A universal identifier like PURL provides both internal developers and external users with direct access to key information about those packages like vulnerabilities and licenses. PURL reduces friction by providing continuity across tools, processes, development environments, and ecosystems. 

It’s not complex. The idea behind PURL was to find a simple way to identify a software package based on its name.  Just by looking at the code, you can determine the Package URLs of the open source packages that you are using. PURLs are defined by the intrinsic nature of the software you observe, and that makes the difference.

A car is a good analogy for demonstrating the superpower of easily identifying something just by looking at it. You can determine the make and model of a car by observing it. You can then uniquely identify by looking at the license plate.

In contrast, identifiers previously used for software packages are complicated. In the world of security, the National Vulnerability Database (NVD) uses an identifier for software packages called Common Platform Enumeration (CPE).

Extending the car analogy, identifying the CPE is like trying to find the internal model number from the manufacturer: you need to have access to extra information that are not obvious and not readily available by watching the car. Using CPEs to query the NVD requires prior knowledge of this extra information and arbitrary assigned identifiers, adding complexity with an additional step.

Package URLs, in comparison, are simple and easy for developers to know what the package actually is! By looking at the car, we can easily observe the make, model, color, condition, and the license plate number, which we can use to universally identify the car more efficiently. Finding the internal manufacturer part number with a central authority to identify it is too cumbersome. PURL brings us simplicity.

PURL can be extremely helpful for organizations mitigating high-profile security issues related to open source package vulnerabilities. More information is usually required to fix these vulnerabilities than what you can discover by looking at the code. The conjunction of several high-profile security issues heightened the need to figure out what third-party software packages are included in many software products. 

For example, there was that major security bug with Log4j, which was really in Log4j version 1.2.17. How can you know if you use Log4j v1.2.17 when there’s a security issue? It’s powerful to know just by looking at the code. But if you need to know that it’s called apache:log4j, then it’s much harder and this is required to query NVD. 

PURL removes the friction to search complex auto-generated values in databases. This makes PURL even more useful for the larger software development community.

How PURL was made

The origins of PURL can be traced very specifically to 2017 when we needed a new way to identify packages in ScanCode Toolkit.

As part of ScanCode v3, we designed parsers for package manifests, like a Maven POM, a Python setup.py, and a npm package.json. But, it was incredibly difficult to quickly identify these packages across ecosystems. We considered different schemas for different environments, but quickly understood that would be way too complicated. After looking at existing options in different open source communities, we discovered a Google project called Grafeas.

Grafeas defined something promising and wonderfully simple called resource URLs, derived from and contributed by JFrog and their product JFROG XRAY. In a resource URL, a node package would be identified as npm://name@version. This is quite similar to URL nomenclature, but modifying the prefix to identify the development environment and then, essentially a name:version. Grafeas was already in use in various places, so we created an issue describing a few details to work out and pinged R2wenD2, who was actively working on the project.

I also reached out to the OSS Review Toolkit (ORT) project to discuss best practices for identifying packages across ecosystems related to AboutCode data specs. At that time, we used a system with a name, namespace, and version for some packages, based on the resource URLs in Grafeas. But, we still needed a common syntax to easily identify these packages in and across different ecosystems. 

Open source projects like Grafeas, Libraries.io, Fabric8 from RedHat, and several others were all doing similar things, but none solved this issue. I cherry-picked the best components of each, and built the first version of Package URL in late October 2017.

As part of nexB’s core principle of FOSS for FOSS, we moved PURL to a new, separate organization on GitHub to better collect effective feedback and share ownership. We invited every key contributor as a co-maintainer/co-owner, including R2wenD2 from Google, Sebastian Schubert from ORT, and later on Steve Springett from CycloneDX, who was one of PURL’s early adopters and for which, the spec was key.

Relinquishing exclusive control early on but maintaining a strong design direction with the key contributors was critical for the ongoing development and success of the PURL project.

With the AboutCode projects, PURL is the critical connector. Whether it’s detecting a package in ScanCode Toolkit, looking for vulnerabilities in VulnerableCode, or reporting complex scans of container images in ScanCode.io, the output is PURLs. The input is PURLs whenever we consume a CycloneDX or SPDX SBOM. We can easily consume and exchange information extracted by PURLs from other tools. That has proved critical to the success of these open source projects.

Casting PURL in the real world

The basic identification of packages is simple and easy. But, there are many levels of depth beyond the package name and version, including the metadata details, like the software license, that APIs can look up. This gets tricky when the metadata details are not documented effectively or the documentation is poor or messy. All this adds more complexity!

Part of the overall identification process is knowing what files were provisioned or provided by the software package – this is very important in verifying the integrity of a package. Once the package is identified and installed on the machine, then you need to ensure that it really is what it’s supposed to be.

There are all these layers, which matter when you don’t have any package manifest or structured information about the package. It’s more complex because you need to accumulate different clues to find the potential origin, like copyright and permissions, URLs, processing READMEs of semi-structured information, and eventually matching. 

Matching is performing a lookup across a larger database of known packages. In modern software development, the vast majority of packages will come with a PURL and don’t need any kind of matching. Matching is the signatory technique to help when there is murkier or more difficult information.

In some cases, matching is used for Microsoft .NET and NuGet packages. Each NuGet package is a set of files, typically DLLs and executables and they may be installed and bundled together. Once this has happened, you don’t know anymore which DLLs came from which NuGet, with NuGet now being the package. It’s not easy to find just by observing the deployed binaries. It requires some matching back to each of the packages to figure out, like “Oh! This DLL came from this Microsoft NuGet, and this other DLL came from this Acrobat NuGet.” Some high level matching of whole files can be very useful to complete the identification, typically NuGet, Apache Maven, or Java environments.

Dependency resolution is being able to literally unwind the twine ball. First, you state the direct dependencies – you need this and that and this package, and this version or a version range. Next, you go for the second level of dependencies, and then, the third level, until you go all the way down. 

There is a complex set of software code called “solvers” or “dependency resolvers”, that ensure the set of versions are compatible together. The input for these solvers is a set of package versions (and in some cases, package version ranges) to find all the dependencies in the complex dependency trees. Each package manager uses their own conventions and approaches to list the various constraints so there is no easy way for a unified approach to dependency resolution. 

The AboutCode team is currently working on Vers, as a universal standard for version ranges identifiers to enable universal dependency resolution across all package managers and to express constraints across system packages and application packages. 

Dependency resolution is designed to determine which version for a given application, and then fetch this installed version. Typically, package managers – like npm, pip for Python, a bundler for Ruby or Python – perform the dependency resolution, and once they find the release of a package to install, they download, extract and install them. 

Looking at software that’s already been built, there’s nothing to understand about dependency resolution that previously happened. There’s a set of packages downloaded and installed by the package management tool in real-time, so dependency resolution matters most during the development when building the software. Upstream, this can be an extremely complex and difficult process of reverse engineering the dependency resolution.

A new approach called Non-vulnerable dependency resolution merges and combines the dependency constraints, which are functional dependencies, to avoid using packages.

The amount of code that can be identified by PURL depends on the environment. For more general purpose software like web, backend, desktop, and mobile development, usually 95 to 99% of the code used comes from package repositories – unless you use proprietary code, of course. But for the code that has third-party open source origins, everything is easily identified by PURL.

The main difference in PURL’s efficacy is in embedded vs non-embedded software development.

Embedded systems or environments using native code like C or C++ are more complex for PURL because these embedded systems don’t typically utilize a package manager. There are some new package managers for embedded systems like Yocto and buildroot for Linux and Conan for C++.

Tools for embedded systems like Yocto for Linux or buildroot may not use PURL, but still have a strong traceable origin of the code. In other cases, the “generic” type with a download URL can be used as a qualifier. So even if they may not use PURL, there is a good enough approach that can handle these exceptions.

In general, there’s no such thing as package managers, and PURL can still be used, but it’s going to be a bit more complex to do proper identification there – which is the big difference between embedded vs. non-embedded kind of software development. With caveats also because you have tools for embedded development now such as Yocto or buildroot that may not use PURL but still have a very strongly traceable origin of where the code comes from. In other cases we can use the “generic” type with a download URL as a qualifier.  So even if they may not use PURL, there is a good enough way that you may not use them all the time but helps deal with these exceptions!

PURL of a FOSS price

PURL makes identification easy, across tools and ecosystems. The ability to compose with other tools – and those tools being free and all available with PURL as a mostly universal identifier – means users don’t have to struggle with integrations and can choose the best-in-class tool they want to use.

PURL was originally built for Python because that’s the language of preference for ScanCode Toolkit. But the specification and libraries for PURL libraries are simple enough that there are now implementations in C#, .NET, JavaScript, Go, Java, Ruby, Swift, Python, PHP, Rust and more. We even have more than one PURL implementation in Java for instance. A list of the available implementations is available at https://github.com/package-url/. 

PURL was specifically designed to not be unique to any organization’s projects. As a new open source standard, PURL helps the ecosystem of SCA tools and provides more flexibility and more options for end users to replace, exchange, and combine tools together using PURL.

As Jackie Kennedy meant to say, “PURLs are always appropriate.” 

Until now, these contexts have been considered as separate domains:

• Package management tools resolve the version expression of the dependent package of a package to resolved versions in order to install the selected versions.


• Security tools check if resolved package versions are affected by known vulnerabilities (even when integrated in a package management tool)

As a result, the typical approach to get a non-vulnerable dependency tree is:

1. Resolve a dependency tree and install the resolved package versions.


2. For each resolved dependent package version, translate the identifiers and look in a vulnerability or bug database to determine if a version is affected by a vulnerability and which package version fixes this vulnerability, if any.


3. Update the vulnerable versions with fixing versions.


4. Repeat step 1 until you have exhausted all possibilities. Stop on conflicts if a resolution is not possible when considering functional requirements and vulnerability fixing versions.

That approach is complex, tedious and time-consuming. It also suggests non-vulnerable versions without consideration for the functional dependency requirements necessary when reconsidering each dependency separately. This is a waste of time and effort as the non-vulnerable suggestion may not satisfy the functional constraints. Stated otherwise, the result may be a non-vulnerable package tree where packages do not work together and do not satisfy functional requirements, e.g., this results in potentially non-functional software.

Here at nexB, we propose a new method and process to resolve software package vulnerable version ranges and dependency version constraints at the same time. This enables developers to obtain a resolved software package version tree matching the blended constraints of functional and vulnerability requirements in order to provide non-vulnerable and up-to-date software code.

The process would go through these typical steps:

1. Given an input software package, collect its direct functional dependency requirements from its manifests and/or lockfiles. Optionally, parse these requirements to normalize them as a Package URLs and a Version Range Specs.


2. Fetch the known package versions set from the ecosystem package registry.


3. Collect known affected package versions ranges and fixed ranges from a vulnerability database or service using the identifiers from step 1.


4. Combine the version ranges of each dependency from steps 1 and 3 in a single new version range and for each dependent package.


5. Feed the combined ranges from step 4 as input to the dependency resolver. Obtain resolved dependencies that satisfies both constraints. The resolver may further request additional versions and ranges using the processes from steps 1 through 4 when new dependent packages are collected during the resolution process.


6. Obtain and output the results of the combined resolution of step 5. Report conflicts and optionally suggest conflict resolutions.

With this new process, we get a resolved package dependency tree with versions that satisfy both functional and vulnerability or bug constraints in a single resolution pass.

It’s worth noting that non-vulnerable dependency resolution is an ongoing process. Developers should regularly monitor their software packages for any newly discovered vulnerabilities and update their packages accordingly. This is particularly important when new vulnerabilities are discovered in commonly used packages, as these can have a significant impact on a wide range of software applications.

In conclusion, non-vulnerable dependency resolution is an essential practice that should be adopted by all developers. By selecting software packages that are free from known vulnerabilities, developers can significantly reduce the risk of security breaches in their software applications. Additionally, regularly monitoring and updating packages, as well as ensuring that packages are obtained from trusted sources, can further enhance the security of software development.

To understand this topic in more detail, read this defensive publication on Non-Vulnerable Dependency Resolution from the Technical Disclosure Commons.

Free and open source (FOSS) code is the essence of modern software. Therefore it is imperative to track FOSS across the supply chain(s). For provenance, licensing, composition and dependencies, security and vulnerability, quality, obsolescence and sustainability. And of course, open source demands open source tooling. In this webinar we’ll explore the state and trends in open source tooling and automation:

• The range of tooling & automation domains and how they are served by leading FOSS tools


• The key trends and insights for supply chain management tooling and SBOMs


• New and upcoming FOSS tools


• How to leverage these and participate to create better, more secure software more efficiently

Watch the recorded webinar on tooling in the software supply chain, Tooling: Software Supply Chain Management Automation with “open source on open source” with nexB co-founder and CTO Philippe Ombredanne.

Starting at 32 minutes, Philippe presents live demos of ScanCode, a server to script and automate the process of Software Composition Analysis, and VulnerableCode, a free and open database of software package vulnerabilities.

PURL, or Package-URL, standardizes existing approaches to reliably identify and locate software packages in a mostly universal and uniform way across programming languages, package managers, packaging conventions, tools, APIs and databases. As a URL string, PURL reliably references the same software package using a simple and expressive syntax and conventions based on familiar URLs.

PURL was originally developed by nexB for use in ScanCode and VulnerableCode, and is now the de-facto standard for vulnerability management and package references by SBOM projects like CycloneDX and SPDX, and in active use by most open source projects that need to identify packages and by many companies and organizations worldwide.