Eclipse SW360 Explained: Component Catalog, License Clearing and SBOMs

Eclipse SW360 is an open source software component catalog, licensed under EPL-2.0, that gives an organization one place to record which components and versions its projects use, what licenses and obligations they carry, how far license clearing has progressed and which known vulnerabilities apply. It hands license scanning to FOSSology and exchanges SBOMs in SPDX and CycloneDX.

SW360 is not a scanner, a package manager or a vulnerability database. It is the system of record between those tools, holding the reviewed, human approved view of your third party software. This guide covers its origin, data model, FOSSology clearing, the SBOM formats the current code accepts, vulnerability matching, how it compares with Dependency-Track, the OSS Review Toolkit (ORT) and FOSSology, and a hands-on lab.

Key takeaways

• SW360 is an Eclipse Foundation project in the Mature phase. Its creation review was held on 21 September 2016, and the initial contribution was copyrighted by Siemens AG and Bosch Software Innovations GmbH.
• The core entities are components, releases, projects, licenses, obligations, vulnerabilities, packages (identified by Package URL), vendors and attachments such as clearing reports and source archives.
• SW360 deliberately does not scan code. It sends a release's source attachment to FOSSology over FOSSology's REST API and tracks the result through a defined set of clearing states, ending in APPROVED only when an accepted clearing report is attached.
• In the current main branch, project SBOM import accepts SPDX 2 documents as RDF/XML (the importer also reads tag-value .spdx files) and CycloneDX as JSON or XML. Project SBOM export writes CycloneDX 1.6 in JSON or XML.
• Vulnerability data comes from a CVE-Search server you run, matched by CPE and then name heuristics, with admin verification and per-project ratings.
• Version 20.0.0 (27 March 2026) removed the old Liferay portal. A SW360 v20 stack is now a Spring Boot backend, CouchDB with Nouveau search, a separate Next.js frontend, Keycloak with PostgreSQL and a reverse proxy, started with Docker Compose.

What is Eclipse SW360 and where did it come from?

SW360 describes itself as "a software component catalogue application designed to provide a central hub for managing software components and their metadata" in its repository README. The Eclipse project page frames the same idea as a central place for sharing information about the software components an organization uses, so that architects and developers can make informed decisions about them.

The Eclipse proposal for SW360 states that the copyright of the initial contribution was owned by Siemens AG and Bosch Software Innovations GmbH, and that the code contributed by the two companies was then licensed under EPL-1.0. Its motive: software is assembled from third party components, so organizations must verify license, export control and IP compliance, share knowledge about components, and know which assets go into which products.

Today the code lives in the eclipse-sw360 GitHub organization, which holds the backend (sw360), the new frontend (sw360-frontend) and the website and documentation repositories. The backend repository was created on 16 April 2018 under its current home and is licensed EPL-2.0. The project page lists the state as Mature, and the "Who's Involved" page names four project leads and a few dozen committers, with all project leads serving on the project's security team.

One inconsistency: the Eclipse governance tab still says the project "is in incubation phase", while the overview says Mature. The overview, the progress reviews (latest dated 26 August 2026) and the release history point to Mature being current.

What problem does SW360 solve?

Every organization that ships software built from open source runs into the same three questions sooner or later.

1. What is in this product? Which components, at which versions, from which sources, in which sub-projects.
2. What do we owe? Which licenses apply, what each license obliges us to do (attribution, source offer, notice files, no endorsement), and whether anyone qualified has actually checked.
3. What is broken? Which of those component versions carry known vulnerabilities, and whether each one matters for this product.

Spreadsheets answer these for one product for a while. They fail when the same release appears in forty products, when legal cleared it once and nobody can find the report, or when a new CVE lands and nobody can say which shipped products contain it.

SW360's answer is reuse. A component and each of its releases is recorded once. Clearing work, license findings and vulnerability assessments attach to that release. Projects then link to releases instead of copying data. When the fortieth project uses the same release, it inherits the clearing work already done.

The proposal is equally clear about what SW360 is not. License scanning and source code scanning are out of scope "because SW360 interacts with and delegates to specialized tools", and SW360 is not meant to act as a version control system. That boundary matters for how you plan a deployment, and it is the source of one of the most common mistakes covered later.

How does the SW360 data model work?

The architecture documentation, published in March 2026 and based on the arc42 template, lists the core entities and their relationships. Here is the model in plain terms.

The relationships are where the reuse comes from. One component has many releases. Projects and releases are many to many, so a release is shared across projects. Releases and licenses are many to many, and so are licenses and obligations. Releases and vulnerabilities are many to many, which means a vulnerability is attached to a release once and shows up in every project linked to that release.

Packages were added to model the reality that the same release often reaches you through a package manager. A Package carries a Package URL (purl), which the architecture glossary calls a standardized way to identify software packages. The same document defines a Package as "a specific distribution of a release, identified by a pURL", and the backend has a dedicated PackageService for managing them.

Projects carry more than a list of releases: the user guide lists fields such as business unit, clearing team, pre-evaluation deadline, delivery start and phase-out dates, and notes that license clearing must be finished before the project delivery date. The tool expects to be a gate in a release process, not a passive inventory.

Roles

Access is role based. The architecture document lists USER, CLEARING_EXPERT, CLEARING_ADMIN, ECC_ADMIN (export control), SECURITY_ADMIN, SW360_ADMIN and ADMIN. Clearing experts work the clearing workflow, clearing admins approve clearings and manage obligations, and security admins own vulnerability verification. Since 20.1.0, security admins can also verify vulnerabilities directly, according to the release notes.

Obligations come from somewhere

Licenses on their own do not tell an engineer what to do. SW360 stores obligations as separate records linked to licenses, at several levels (the REST API accepts project, organization, component and all as obligation levels). The backend also includes an obligation connector for the Open Source Automation Development Lab (OSADL). OSADL publishes open source license obligation checklists that break each license into "YOU MUST" and "YOU MUST NOT" atoms written from a shared vocabulary, so different licenses that impose the same duty use the same words. Importing those checklists gives your clearing team a starting set of normalized obligations rather than free text.

How do release clearing states work?

Clearing is the heart of SW360, and the project documents the rules as a formal business rule, BR-CLR-001, last verified on 7 September 2026. A release's clearingState is computed from its attachments unless a person overrides it.

The evaluation order matters. An attached clearing report wins over everything else; an accepted internal use scan report comes next; an initial scan report next; and only then does the state fall back to NEW_CLEARING. Deleting the clearing report from an approved release drops it back to whichever lower state the remaining attachments justify.

The rule's stated purpose is to make sure a release is "never marked APPROVED without an accepted clearing report." That is the property auditors care about. It also means the quality of your approvals is exactly the quality of the review behind each ACCEPTED check status. SW360 records the decision; it does not make it.

The INTERNAL_USE_SCAN_AVAILABLE state is worth a note. As the OSADL checklist project puts it, obligations are imposed on the distributor whenever open source software is copied and distributed. A component used purely in an internal tool may need a lighter review than one shipped to customers, and this state lets the workflow record that difference rather than forcing every release through the full clearing path.

How does SW360 work with FOSSology?

FOSSology, which its website describes as a Linux Foundation project run by the FOSSology Workgroup, is the license compliance system that does the scanning SW360 delegates. Its README describes it as "an open source license compliance software system and toolkit" that runs license, copyright and export control scans, provides a database and web UI for a compliance workflow, and can generate an SPDX file or a ReadMe with copyright notices. FOSSology also deduplicates, so rescanning a new version of a large codebase only rescans changed files. The latest FOSSology release at the time of writing is 4.7.2, published on 22 September 2026, and FOSSology is licensed GPL-2.0-only.

The current integration path

Older SW360 developer documentation still describes an integration that ran shell scripts on the FOSSology server over SSH. The current backend uses FOSSology's REST API instead. The FossologyRestClient class in the main branch talks to /repo/api/v2/ endpoints with a bearer token, expects a FOSSology API version starting with "2.", and walks through this sequence:

1. Look up folders, so uploads land in the right place.
2. Upload the release's source attachment to /repo/api/v2/uploads with a set of scan options.
3. Poll the job status.
4. Request an SPDX 2 report for the upload with reportFormat=spdx2.
5. Download the generated report and attach it back to the release.

The scan options show what a SW360 triggered scan runs. The current code enables FOSSology's nomos, monk and ojo license agents, copyright and author detection, export control and keyword scanning, plus the MIME and package agents. It turns on the matching deciders and enables reuse of earlier clearing decisions, reports and copyright decisions.

That last part is the payoff. If a clearing expert has already concluded licenses for an earlier version of a component in FOSSology, reuse carries those decisions forward to the new upload, and only changed files need fresh human attention.

What you configure

The backend Docker documentation recommends the official fossology/fossology container image for containerized deployments and says FOSSology setup is still done in the SW360 admin UI or API: you configure the FOSSology URL, a folder ID and an access token. The REST API exposes three release level operations for this flow: triggerFossologyProcess (with options to mark an earlier process outdated and set an upload description), checkFossologyProcessStatus and reloadFossologyReport.

Constraints to plan around

• Each release can have only one attachment of type SOURCE, according to the developer notes. That source archive is what gets sent to FOSSology, so the archive has to be the real source for that version.
• Triggering a FOSSology process moves the release to SENT_TO_CLEARING_TOOL under BR-CLR-001.
• The REST API returns an error if a FOSSology process for the same release is already running, so automation should check status before retriggering.

FOSSology produces findings. A person still has to review them, conclude licenses where scanners disagree, and produce the clearing report that moves the release to APPROVED. The project and FOSSology both say as much: FOSSology's README states that it "does not give legal advice."

Which SBOM formats can SW360 import and export?

This answer comes from the eclipse-sw360/sw360 main branch source and REST docs as of October 2026.

A few details deserve spelling out.

SPDX JSON and SPDX 3 are not accepted by the project importer. The SPDX importer checks the file extension and only proceeds for rdf (including names ending in rdf.xml) and spdx. A .json SPDX document fails that check. The project's own user guide is stricter still and says only SPDX RDF/XML files "with unique described top level node" are supported. If your build produces SPDX JSON, convert it first; the SPDX tools-java utility converts between tag-value, RDF/XML, JSON, XML, YAML and spreadsheet formats. The SPDX site lists 3.0 as the current specification version, with 2.3 and 2.2 as previous versions, and describes SPDX as an international open standard, ISO/IEC 5962:2021. Converting an SPDX 3 document down to SPDX 2 for SW360 can lose fields, which is covered in our SPDX 3 to CycloneDX 1.7 field mapping post.

CycloneDX import groups by repository. The CycloneDX importer maps sanitized VCS URLs to components, so package entries from the same source repository become one SW360 component. Components without a VCS reference are handled separately.

CycloneDX export is 1.6, not 1.7. The exporter calls the CycloneDX generators with Version.VERSION_16 for both JSON and XML. The CycloneDX project lists 1.7 as its current version, standardized as ECMA-424. A 1.6 document is still a valid CycloneDX document; just do not promise a downstream consumer 1.7 features from a SW360 export. The CycloneDX 1.7 features review covers what 1.7 adds.

The export needs linked releases or packages. The exporter refuses to export a project that has no linked releases or packages and returns a "failed sanity check" message.

Over the REST API, SBOM import is a multipart POST to /projects/import/SBOM with a type parameter of SPDX or CycloneDX. Import into an existing project is /projects/{id}/import/SBOM and is CycloneDX only. Exports go through the reports endpoint with module=sbom and a bomType of JSON or XML.

How does SW360 match vulnerabilities?

SW360 does not ship a vulnerability feed. It connects to a CVE-Search server, an open source tool that imports CVE and CPE data into MongoDB, and you run that server yourself. The SW360 CVE scheduler documentation says this outright and notes that an online CVE server SW360 used to reach "is not active." For testing, the backend Docker guide mentions a public CVE-Search instance and labels it for testing only.

Scheduling

By default the CVE-Search sync is scheduled nightly at midnight: an offset of 0 seconds after midnight and an interval of 86,400 seconds. The scheduler does not auto start the CVE-Search service by default; you add cvesearchService to the autostart setting or start it from Admin, Schedule. Until the first run finishes, the user guide notes, SW360 does not know any vulnerabilities for your project.

Matching heuristics

Matching starts with the release's CPE. If the release has a valid CPE (beginning with cpe: and longer than ten characters), SW360 searches by CPE. If that fails, it falls back to heuristics that guess vendor and product names. The guessing heuristic compares the release's vendor and name against CVE-Search's lists of real vendors and products, first with the version and then without it.

Closeness is measured with a modified Levenshtein distance. The modification makes skipping a space separated prefix or suffix in the release data free, so "needle" has distance 0 to "prefix needle postfix". The project vulnerability view then shows, for each match, the distance and the "needle" that produced it, plus a summary of how many matches came from an exact CPE and how many from heuristics at each distance.

Name based matching finds things a strict matcher misses but also produces false positives, especially for common names. SW360's answer is human verification.

Verification and rating

There are two separate human controls.

Verification answers "does this CVE really apply to this release?" once, for every project. Rating answers "does it matter for this product?" per project. Both keep a change history with who, when and a comment. If you have used VEX, the project rating will feel familiar: it is a per product exploitability judgment, stored in SW360 rather than exchanged as a document.

How this compares with Dependency-Track

Dependency-Track describes itself as a component analysis platform built on SBOMs, and its documentation says it consumes and produces CycloneDX. For vulnerabilities, it matches components that have a CPE against NVD data following the NIST CPE name matching specification, with extra checks to reduce false positives, and runs analyzers that match components by Package URL. Its vulnerable software dictionary is populated from mirrored sources that include the NVD and OSV. Analysis results are cached, by default for 12 hours.

In short: for continuous answers to "which SBOMs contain a vulnerable package?", Dependency-Track is built for that, and our post on whether Dependency-Track is a scanner or an SBOM platform goes deeper. For recording what legal has cleared per release and reusing it across products, SW360 is built for that. Many teams run both.

What is the SW360 architecture in version 20?

Version 20.0.0 was the biggest architectural change in the project's history. Its release notes say the legacy Liferay UI was removed entirely, the backend is now "fully decoupled", and users must set up the new Next.js frontend from the separate sw360-frontend repository. The same release added extensive OpenAPI documentation, database side pagination and fixes for XXE and path traversal issues. Version 20.1.0 then moved to Spring Boot 4.x and Spring Security 7.x, added multi-issuer JWT support and Cloudant connection pooling, and flagged two breaking changes to review on upgrade.

The architecture document's technology table for the current stack:

Inside the backend, a REST layer (authorization server and resource server) sits in front of Thrift services. The architecture document says Thrift was introduced to integrate with FOSSology when neither FOSSology nor SW360 had a REST API. Today the project's versioning policy says the Thrift API "is not considered a public API anymore". The REST API is the contract for integrations.

CouchDB stores everything as documents in databases such as sw360db, sw360users and sw360attachments. The architecture document points to CouchDB's revision system and a dedicated changelog database as the basis for audit trails.

Containers and ports

The v20 container guide on the SW360 site is deliberately short and points to the frontend repository's README_DOCKER.md as the source of truth. A typical v20 stack has these services:

Both the frontend Docker guide and the container page carry the same warning in different words: the compose setup is a reference or starter stack, every shipped secret and password is a placeholder, and operators must adapt and harden URLs, secrets, certificates, network exposure and image tags before production use.

Authentication

The API access guide lists HTTP Basic, API tokens, OAuth2 client credentials, OAuth2 authorization code with PKCE, and Keycloak OIDC. The backend README says Basic auth is disabled in production profiles and should stay that way. Reads need a read capability and writes a write capability.

SW360, Dependency-Track, ORT and FOSSology compared

These four open source projects get mentioned together because they cover overlapping parts of the same job. They are not substitutes for each other.

ORT deserves a sentence on its own, because it is the natural feeder for SW360. Its README lists the Analyzer (resolves dependencies across package managers), Downloader, Scanner (wraps license scanners such as ScanCode behind one API), Advisor, Evaluator (policy rules against gathered data), Reporter and Notifier. The Reporter can write CycloneDX BOMs, SPDX 2.2 documents and NOTICE files. ORT's latest release at the time of writing is 97.2.0, published on 22 October 2026. A common pattern is ORT in CI producing a CycloneDX BOM that is pushed into SW360 through the REST import, so the catalog always reflects what the build actually resolved. Our ORT license compliance post covers the ORT side.

Dependency-Track's latest GitHub release at the time of writing is 5.2.0 (8 October 2026); its v4 documentation site points to separate v5 docs.

Step by step: run SW360, import an SPDX SBOM, clear licenses, export reports

This lab builds the official reference stack, imports an SPDX SBOM, follows a release through clearing and exports the reports, using the REST API so you can automate it. Endpoint names come from the SW360 REST controllers in the main branch; confirm parameters for your version in the Swagger UI the stack serves at /resource/swagger-ui/index.html.

Step 1: prerequisites

You need Docker with Compose V2 (or Podman), access to pull images from ghcr.io and upstream registries, and a few GB of free RAM.

Step 2: get the reference stack and replace the session secret

git clone https://github.com/eclipse-sw360/sw360-frontend.git
cd sw360-frontend

# Replace the shipped placeholder session secret
openssl rand -base64 32 | tr -d '\n' > config/front-end/nextauth_secret

The guide says to regenerate all placeholder secrets before any real use.

Step 3: set build time values, build and start

The frontend bakes its API URL and auth provider into the client bundle at build time. Edit the sw360-frontend service's build.args in docker-compose.yml:

  sw360-frontend:
    build:
      context: .
      args:
        NEXT_PUBLIC_SW360_API_URL: https://localhost
        NEXT_PUBLIC_SW360_AUTH_PROVIDER: keycloak   # keycloak | sw360oauth | sw360basic
        NEXTAUTH_URL: https://localhost

Then build and start:

docker compose -f docker-compose.yml build sw360-frontend
docker compose -f docker-compose.yml up -d
docker compose ps
docker compose logs -f sw360-frontend

Once healthy, Nginx serves the frontend at https://localhost/, the REST API at https://localhost/resource and Keycloak at https://localhost/kc. The default certificate is a self-signed snakeoil certificate, so your browser and curl will warn until you replace it.

The guide documents default lab credentials of setup@sw360.org with password sw360fossie. Change them before the instance is reachable by anyone else. For Keycloak based login, run the one time Keycloak bootstrap with the OpenTofu or Terraform script in third-party/keycloak-tf in the backend repository, then wire the Keycloak client secret as the guide describes.

Step 4: set up API access for the lab

For a throwaway local lab, Basic auth is the quickest way to try the API. For anything longer lived, create an API token or use OAuth2 client credentials, as the API access guide recommends.

export SW360_HOST='https://localhost'
export RESOURCE_API="$SW360_HOST/resource/api"
export SW360_USER='setup@sw360.org'
read -s SW360_PASS && export SW360_PASS

# Smoke test: list five projects (-k only because the lab cert is self-signed)
curl -sk --user "$SW360_USER:$SW360_PASS" \
  "$RESOURCE_API/projects?page=0&page_entries=5"

A 401 means wrong credentials or Basic auth disabled; a 403 on a write means your user lacks the write capability.

Step 5: get your SBOM into a format SW360 accepts

If your SBOM is already SPDX RDF/XML or tag-value, skip this. If it is SPDX JSON, convert it with the SPDX tools-java utility, which infers formats from file extensions:

# Use the tools-java release jar you downloaded from the spdx/tools-java project
java -jar tools-java-2.0.7-jar-with-dependencies.jar Verify app.spdx.json
java -jar tools-java-2.0.7-jar-with-dependencies.jar Convert app.spdx.json app.rdf
java -jar tools-java-2.0.7-jar-with-dependencies.jar Verify app.rdf

Check that the document's documentDescribes points at your top level package. If it does not, the importer reports that the BOM "did not contain any top level packages" and creates nothing.

Step 6: import the SPDX SBOM as a project

curl -sk --user "$SW360_USER:$SW360_PASS" \
  -X POST \
  -F "file=@app.rdf" \
  "$RESOURCE_API/projects/import/SBOM?type=SPDX" | tee import.json

A 201 means SW360 created a project, plus components and releases for the packages it found. The import checks for duplicates, which is why naming discipline matters (see Common mistakes).

For CycloneDX, use type=CycloneDX with a .json or .xml file. To refresh an existing project from a newer CycloneDX BOM, post to the project specific endpoint instead, and add doNotReplacePackageAndRelease=true if you want to add new data without replacing the existing links:

curl -sk --user "$SW360_USER:$SW360_PASS" \
  -X POST \
  -F "file=@bom.cdx.json" \
  "$RESOURCE_API/projects/$PROJECT_ID/import/SBOM?doNotReplacePackageAndRelease=true"

Step 7: review the project's clearing status

export PROJECT_ID='<id from import.json>'

curl -sk --user "$SW360_USER:$SW360_PASS" \
  "$RESOURCE_API/projects/$PROJECT_ID/licenseClearing" | jq .

Each linked release shows its clearing state. Expect most to start at NEW_CLEARING. Releases already cleared for another project keep their state, which is the reuse working.

Step 8: send a release to FOSSology and attach the result

First, in the admin UI or API, configure the FOSSology connection: the FOSSology URL, the folder ID and an access token. Make sure the release has exactly one SOURCE attachment containing the real source archive for that version. Then:

export RELEASE_ID='<release id>'

curl -sk --user "$SW360_USER:$SW360_PASS" \
  "$RESOURCE_API/releases/$RELEASE_ID/triggerFossologyProcess?uploadDescription=sw360-lab"

# Poll until the process finishes
curl -sk --user "$SW360_USER:$SW360_PASS" \
  "$RESOURCE_API/releases/$RELEASE_ID/checkFossologyProcessStatus"

The release moves to SENT_TO_CLEARING_TOOL. When FOSSology finishes, SW360 fetches the SPDX report and attaches it to the release. A clearing expert then reviews findings in FOSSology, concludes licenses where agents disagree, and the resulting clearing report is attached to the release. When the clearing report's check status is set to ACCEPTED, the release becomes APPROVED.

Step 9: check obligations

curl -sk --user "$SW360_USER:$SW360_PASS" \
  "$RESOURCE_API/projects/$PROJECT_ID/licenseObligations" | jq .

curl -sk --user "$SW360_USER:$SW360_PASS" \
  "$RESOURCE_API/projects/$PROJECT_ID/obligation?obligationLevel=project" | jq .

The first lists license obligations from linked releases; the second lists project level obligations. Update each obligation's status as the product team fulfills it.

Step 10: export the reports

# Clearing report (DOCX)
curl -sk --user "$SW360_USER:$SW360_PASS" -o project-clearing-report.docx \
  "$RESOURCE_API/reports?module=exportCreateProjectClearingReport&projectId=$PROJECT_ID&generatorClassName=DocxGenerator&variant=REPORT"

# License disclosure document (Readme OSS style text)
curl -sk --user "$SW360_USER:$SW360_PASS" -o LicenseInfo.txt \
  "$RESOURCE_API/reports?module=licenseInfo&projectId=$PROJECT_ID&generatorClassName=TextGenerator&variant=DISCLOSURE"

# CycloneDX 1.6 SBOM of the project
curl -sk --user "$SW360_USER:$SW360_PASS" -o project.cdx.json \
  "$RESOURCE_API/reports?module=sbom&projectId=$PROJECT_ID&bomType=json"

The license info endpoint documents two variants: DISCLOSURE with the Text or XHTML generators, and REPORT with the DOCX generator. The UI equivalent is the project's License Clearing tab, where "Generate license info" produces a Readme OSS file and "Generate Source Code Bundle" builds a zip of the selected source archives for licenses that require a source offer.

Step 11: schedule vulnerability sync

Point SW360 at your CVE-Search server (the backend image build accepts --cvesearch-host), enable the service in the scheduler, then work the project's Vulnerabilities tab.

Governance, committers and release cadence

SW360 runs under the Eclipse Foundation Development Process (EDP) and the Eclipse IP Policy. Under the EDP, a project in the Mature phase has "demonstrated that they are an open source Project with an open and transparent process, an actively involved and growing community, and Eclipse-quality technology." Projects hold periodic progress reviews; SW360's project page lists one dated 26 August 2026 and another scheduled for August 2027. Before any release, the EDP requires the project lead to assert that the IP Policy has been followed.

The committer pathway describes users, contributors, committers (elected after sustained contributions) and project leads, and names Siemens, Toshiba, CARIAD and Bosch among organizations it invites. Contributions require an Eclipse Contributor Agreement and DCO sign off, according to the architecture document's constraints section.

Versioning follows semantic versioning with project specific rules:

• A major version is triggered by REST API breaking changes or by any change that needs a database migration script. The Thrift API no longer counts as public.
• Before a major release the repository enters a code freeze: no new features, no dependency updates, only decided bug fixes, with security vulnerability fixes as the only exception.
• During a freeze, a major vulnerability in a dependency must be fixed even if the release date slips. A medium one is tested and merged if it validates in reasonable time.

The timeline above shows the practical cadence: roughly one major version a year, with minor and patch releases between, and release notes that call out breaking changes. The upgrade from 18 to 20 has its own guide.

The project also generates its own SBOM: a release_sbom.yml workflow runs the CycloneDX Maven plugin, and the README shows an OpenSSF Best Practices badge.

Common mistakes

Treating the catalog as a scanner. SW360 only knows the components someone imported or entered. If a build pulls a new transitive dependency and nobody refreshes the project, SW360 will not see it. Feed it a BOM from each build and keep a scanner in CI.

Never updating component metadata. Matching depends on each release's CPE, vendor and name. A release with no CPE and a vague name falls through to heuristics, with misses and false positives. Follow SW360's component naming best practices and add CPEs and purls.

Creating duplicate components. "commons-io" and "Apache Commons IO" as two components means two clearing histories and no reuse. Agree a naming convention and merge duplicates when you find them.

Approving without a real clearing report. BR-CLR-001 ties APPROVED to an accepted clearing report. Marking reports ACCEPTED without review defeats the control and leaves an audit trail that says otherwise.

Uploading the wrong source archive. One SOURCE attachment per release goes to FOSSology. A binary, a different tag or a repackaged archive gives a clean looking scan of the wrong code.

Assuming SPDX JSON or SPDX 3 imports will work. The project importer accepts SPDX 2 RDF/XML and tag-value. Convert first and verify the converted file.

Promising CycloneDX 1.7 from a SW360 export. The exporter writes 1.6. Downstream consumers that need 1.7 fields will need a conversion step and a check for loss.

Running without a CVE-Search server. Without one, the vulnerability tab stays empty, which looks like "no vulnerabilities" to anyone who does not know better.

Exposing the reference stack. Default credentials, placeholder secrets and a snakeoil certificate are fine on a laptop and dangerous anywhere else. Follow the "Securing SW360" guide first.

Skipping release notes on upgrade. 20.0.0 removed the Liferay UI, and 20.1.0 lists breaking changes. Test on a copy of your CouchDB data first.

FAQ

Is Eclipse SW360 free to use?

Yes. SW360 is open source under the Eclipse Public License 2.0, and you run it yourself.

Who created SW360?

The Eclipse proposal states that the copyright of the initial contribution was owned by Siemens AG and Bosch Software Innovations GmbH. The project then moved to the Eclipse Foundation, where its creation review took place on 21 September 2016.

Does SW360 scan source code for licenses?

No. License and source code scanning are explicitly out of scope. SW360 sends source archives to FOSSology through FOSSology's REST API, receives an SPDX report back, and tracks the human clearing process around it.

Can SW360 import CycloneDX SBOMs?

Yes. In the current main branch, CycloneDX JSON and XML files can create a new project or refresh an existing one through the REST API. SPDX 2 RDF/XML and tag-value files can create new projects.

What SBOM format does SW360 export?

Project SBOM export produces CycloneDX 1.6 in JSON or XML. License information exports produce text, XHTML or DOCX documents, and project lists can be exported as XLSX, CSV, JSON or XML.

Where does SW360 get vulnerability data?

From a CVE-Search server you run, synced nightly by default and matched by CPE, then name heuristics.

Does SW360 still use Liferay?

No. Version 20.0.0, released on 27 March 2026, removed the Liferay UI. The UI is now a separate Next.js application in the sw360-frontend repository.

What is a clearing report in SW360?

A clearing report is the formal document attached to a release after a license review. When its check status is ACCEPTED, the release's clearing state becomes APPROVED, and its license information can flow into project disclosure documents.

Where Safeguard fits

Safeguard does not integrate with SW360 today, and nothing in Safeguard's documentation describes an SW360 connector, so do not plan around one. Safeguard also does not do legal license clearing; a person still concludes licenses and signs off obligations. The overlap is in the parts SW360 depends on other tools for. Safeguard generates SBOMs from repositories, container images and existing SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, with JSON results under ./output) and exports them in SPDX and CycloneDX. It accepts SBOMs created by other tools for vulnerability analysis and monitoring, so a CycloneDX file exported from SW360 can be uploaded and matched against vulnerability databases, with reachability analysis ranking what your code actually calls. Its license compliance features identify licenses using the SPDX license list, classify them by obligation category, enforce license policies in CI and on pull requests, and generate NOTICE and attribution files. The platform also shows which projects contain a given component and version, which is the same "where is it?" question SW360's catalog answers from its side.

A catalog like SW360 tells you which component versions your products ship and which of them carry known vulnerabilities, but it cannot move any of those versions. The open source dependencies behind every cleared release still need patched versions to reach your builds, and that is the supply chain side of keeping a clean catalog.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency scanning and remediation in Safeguard, not SW360 itself. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Run against the repository that produces a product's SBOM, the same scan gives you an inventory of packages and versions to compare with what SW360 has recorded for that project, so drift between the build and the catalog shows up quickly.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: asked to fix the lodash CVE in a repository, it reads the finding and the advisory, edits package.json to lodash 4.17.21 and runs npm install and npm test, asking before any command that changes something and pushing nothing. The same flow applies when SW360's vulnerability tab rates a CVE as applicable for a project and someone has to bump the dependency in the code that ships.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version and get the answer from your own scan data, a useful cross check when a release in SW360 is flagged and you need to know where else it is deployed.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Eclipse SW360 project page (Eclipse Foundation)
• Eclipse SW360 governance tab
• Eclipse SW360 Who's Involved
• Eclipse SW360 project proposal
• Eclipse SW360 website
• SW360 backend repository and README
• SW360 releases on GitHub
• SW360 20.0.0 release notes
• SW360 20.1.0 release notes
• SW360 Architecture documentation
• BR-CLR-001: Release clearing state determination
• SW360 Vulnerability Management
• SW360 Search Vulnerabilities
• SW360 CVE Scheduler
• SW360 Version 20.x with Containers
• SW360 Frontend Docker guide
• SW360 Backend Docker guide
• SW360 API Access guide
• SW360 Project user guide
• SW360 FOSSology Integration (developer notes)
• SW360 Release and Versioning
• SW360 Committer Pathway and Community Governance
• SW360 SpdxBOMImporter.java
• SW360 CycloneDxBOMImporter.java
• SW360 CycloneDxBOMExporter.java
• SW360 FossologyRestClient.java
• SW360 ProjectController.java
• SW360 ReleaseController.java
• SW360 SW360ReportController.java
• SW360 OSADLObligationConnector.java
• SW360 projects REST API docs (projects.adoc)
• SW360 pom.xml (library versions)
• FOSSology website
• FOSSology README
• FOSSology 4.7.2 release
• OSS Review Toolkit documentation
• OSS Review Toolkit README
• ORT Scanner documentation
• ORT Reporter documentation
• ORT 97.2.0 release
• Dependency-Track documentation
• Dependency-Track known vulnerability analysis
• Dependency-Track 5.2.0 release
• SPDX specifications
• SPDX tools-java README
• CycloneDX specification overview
• OSADL Open Source License Checklists
• CVE-Search
• Eclipse Foundation Development Process
• Safeguard docs: License Compliance
• Safeguard docs: Upload existing SBOMs

Last reviewed: 25 October 2026. SW360 changes quickly between releases; check the release notes and the Swagger UI of your version before relying on a specific endpoint or format.