Tools / Free and Open Source Software Analysis (FOSSA) Interview questions

FOSS is software whose source code is published under a license that lets anyone use, study, modify and redistribute it. Think Linux, PostgreSQL, Kubernetes or the Apache HTTP Server.

The word "free" is about freedom, not price. A FOSS project can still be sold or supported commercially, and the license still carries conditions such as keeping copyright notices or sharing changes.

Open source here usually means a license approved against the Open Source Definition maintained by the OSI. Code that is merely visible on GitHub does not qualify.

Examples fall into familiar families: operating systems (Linux, FreeBSD), databases (PostgreSQL, SQLite), languages and runtimes (Python, Go, Node.js) and infrastructure (Kubernetes, Nginx). Most commercial codebases contain open source, often as the bulk of the code, which is why tracking it matters.

FOSSA, short for Free and Open Source Software Analysis, is a platform for managing the open source inside your software. It finds your dependencies, identifies their licenses, flags known vulnerabilities and checks everything against policies you define.

It has two parts: the open source FOSSA CLI, which analyzes your project locally or in CI, and the FOSSA server and web app, which resolves licenses, stores results, enforces policy and produces reports.

Typical outputs are policy issues, security findings, attribution notices and SBOM exports.

A typical rollout connects repositories or adds the CLI to CI, assigns a license policy, then works through the backlog from the first scan. Teams then tighten the gates so new pull requests cannot add denied licenses or critical vulnerabilities.

It is the practice of meeting the obligations attached to every open source component you ship or run. Each license says what you must do, and compliance means you actually do it.

A workable cycle looks like this:

1. Inventory every direct and transitive component.
2. Identify the license of each one.
3. Check licenses against your company policy.
4. Fulfill obligations such as attribution, notices or source offers.
5. Re-check on every release, because dependencies change.

Getting this wrong can mean forced source disclosure, injunctions or a failed acquisition review.

Obligations differ by license. Permissive licenses mostly ask for notices, weak copyleft asks you to share changes to the covered library, and strong copyleft can reach your own code if you distribute a combined work. How you use the code also matters: shipped in an app, packed in a container, or only run on your servers.

SCA identifies the third-party and open source components in your codebase, then maps each one to its license and to known vulnerabilities. It answers the question: what did we actually pull in, and is it safe and allowed?

It differs from static application security testing, which inspects the code you wrote.

FOSSA is an SCA tool.

Modern SCA builds the full dependency graph instead of only top-level packages, and can export the result as an SBOM. Its accuracy depends on good input, which is why lockfiles and build metadata matter so much.

Permissive licenses let you use code in proprietary products with very few conditions. Common ones are MIT, BSD-2-Clause, BSD-3-Clause, ISC and Apache-2.0.

The usual requirement is to keep the copyright and license text with your distribution. You do not have to release your own source code.

Apache-2.0 adds an explicit patent grant and expects you to carry along any NOTICE file and mark files you changed. That patent language is why many companies prefer it to MIT for larger projects.

Permissive does not mean no obligations. Forgetting the notice text for hundreds of MIT and BSD packages is probably the most common real-world violation, which is why teams generate the attribution file automatically at release time.

A copyleft license requires that derivative works be shared under the same or a compatible license when you distribute them. It uses copyright to keep code open, not to close it.

Strength varies:

• Strong: GPL-2.0 and GPL-3.0 cover the whole combined work.
• Weak: LGPL and MPL-2.0 limit the requirement to the library or the changed files.
• Network: AGPL-3.0 also triggers when users interact with the program over a network.

The trigger is normally distribution, and the boundary of a "derivative work" is the hard legal question.

For example, statically linking a GPL-3.0 library into a program you ship generally means offering that program under GPL-3.0 too. Calling the same code as a separate program over a pipe or HTTP is usually treated differently, though lawyers still look at how intimate the integration is.

Licenses are usually grouped by how much they ask of you:

Source-available licenses such as BUSL, SSPL and Elastic License 2.0 look similar but restrict use, so the OSI does not treat them as open source.

Also check for exceptions and add-ons. The Classpath exception on some GPL code relaxes linking rules, and clauses like the Commons Clause add restrictions to an otherwise familiar license. The exact text matters more than the name.

It is a short, standard string for a license, defined by the SPDX project. MIT, Apache-2.0 and GPL-3.0-only are examples. It removes the ambiguity of just writing "GPL", which could mean several versions.

SPDX also defines expressions for combining licenses:

MIT OR Apache-2.0
GPL-2.0-only WITH Classpath-exception-2.0
BSD-3-Clause AND MIT

You can tag a source file with one line:

// SPDX-License-Identifier: Apache-2.0

Scanners like FOSSA normalize detected licenses to these IDs.

The suffixes matter. GPL-2.0-only means version 2 exclusively, while GPL-2.0-or-later lets you pick a later version. Older metadata still uses the deprecated GPL-2.0 and GPL-2.0+, and scanners map those for you.

An SBOM is a machine-readable inventory of everything inside a piece of software: components, versions, suppliers, licenses and how they depend on each other. It works like an ingredients list.

Two formats dominate: SPDX and CycloneDX.

Teams use SBOMs to answer "are we affected?" within minutes when a new CVE drops, to support license audits, and to meet customer or regulatory requests. US Executive Order 14028 in 2021 pushed SBOMs into mainstream procurement.

A good SBOM names each component with a stable ID such as a Package URL, for example pkg:npm/express@4.18.2, so tools can reliably match it to license and vulnerability data. Keep one per release so you can answer questions about older shipped builds.

A direct dependency is one you declare yourself in a manifest such as package.json or pom.xml. A transitive dependency is pulled in by one of those, and by its own dependencies in turn.

my-app
└── express            (direct)
    ├── body-parser    (transitive)
    │   └── bytes      (transitive)
    └── cookie         (transitive)

Most of the dependency count, and most surprises, sit in the transitive layer. A scanner must follow the whole tree because a GPL package three levels down still matters.

Depth affects fixes too. You can bump a direct dependency yourself, but to fix a vulnerable transitive package you may need the direct dependency to publish an update, or use an override or resolution feature in your package manager.

The FOSSA CLI is the command-line tool, named fossa, that analyzes your project and talks to the FOSSA server. It is open source and runs on a laptop or in a CI job.

Main commands:

• fossa analyze - finds dependencies and uploads the result.
• fossa test - checks results against policy and sets the exit code.
• fossa report - fetches reports such as attribution.
• fossa container analyze - scans container images.
• fossa list-targets - shows what the CLI discovered.

Authentication uses the FOSSA_API_KEY environment variable.

Because the CLI runs inside your own CI, it sees the real lockfiles and build tools. For ordinary dependency analysis it sends the dependency graph and metadata rather than your whole source tree, a point security teams like to confirm during vendor review.

Install the CLI, export your API key, then run analyze from the project root.

export FOSSA_API_KEY=your-key
cd my-project
fossa analyze
fossa test

analyze discovers manifests, builds the dependency graph and uploads it. test waits for the server to finish and returns a non-zero exit code if policy issues exist.

To look at the result locally without uploading, use fossa analyze --output, which prints JSON to the terminal.

If nothing is found, check that you are in the repository root and that a lockfile exists. A first scan on a mature project often shows a large backlog, so decide early whether to fix it all or block only new issues.

fossa test waits for the latest analysis to finish on the server, evaluates it against the project's policy, and reports the issues it finds. Its exit code makes it usable as a CI gate.

It does not scan anything by itself. You must run fossa analyze first so there is a revision to test.

Add --format json when you want machine-readable output for dashboards or ticket creation, and a timeout so a slow scan does not hang the pipeline forever.

.fossa.yml is the project's configuration file in the repo root. It stores settings so every developer and CI job scans the same way.

version: 3
project:
  id: custom+1234/my-app
  name: my-app
paths:
  exclude:
    - ./test/fixtures
targets:
  exclude:
    - type: npm
      path: ./docs

Typical settings are project name and ID, revision details, and path or target filters. Keep the API key out of this file and use the environment variable instead, since the file is committed.

Explicit command-line flags generally take priority over the file, so a developer can run a one-off scan without editing the committed config. In monorepos, use targets to scan each service separately and give each a clear project name.

A license policy is a set of rules that says which licenses are acceptable. Each license is mapped to an action such as allow, deny or flag for review.

A common setup allows MIT, BSD and Apache-2.0, flags LGPL and MPL for review, and denies AGPL-3.0. Policies are assigned to projects or teams, so a SaaS product and a downloadable desktop app can follow different rules.

When a dependency breaks a rule, it appears as an issue and makes fossa test fail.

Policies can also treat unknown or missing licenses as violations, which is usually worth enabling. Route exceptions through a documented review so that one approved library does not turn into a quiet hole in the policy.

An attribution report is the list of third-party components in a product, with their licenses and copyright notices. You ship it as an "open source notices" page, file or About screen.

MIT, BSD and Apache-2.0 all require that notices travel with the software, so this report is how most teams satisfy them. Generate one from the CLI:

fossa report attribution --format html

Other formats such as text, markdown and JSON are available for different delivery needs.

Place the report where users can find it, such as an About screen, a docs page or a NOTICE file in the download. Regenerate it every release because the dependency list changes, and make sure Apache-2.0 NOTICE content is carried through.

fossa-deps.yml lets you declare dependencies the CLI cannot discover from package manager files, such as copied source, internal libraries or manually downloaded binaries.

It has four sections: referenced-dependencies, custom-dependencies, vendored-dependencies and remote-dependencies.

referenced-dependencies:
  - name: lodash
    type: npm
    version: 4.17.21
custom-dependencies:
  - name: internal-codec
    version: "2.1"
    license: MIT
vendored-dependencies:
  - name: openssl-fork
    path: vendor/openssl

Use the right section for each case. referenced-dependencies takes a type, name and version so FOSSA can look up license data. custom-dependencies lets you state the license yourself, which suits internal code. remote-dependencies points to a downloadable archive.

FOSSA groups findings into three categories:

Licensing issues come from your policy. Security issues come from vulnerability data matched to package versions. Quality issues are generally lower priority but help you plan upgrades.

Policy decides what counts in practice. The same package can be fine in a downloadable app and denied in a SaaS product, so a licensing issue only makes sense relative to the policy attached to the project.

CVE stands for Common Vulnerabilities and Exposures. It is a unique ID such as CVE-2021-44228 given to one publicly disclosed vulnerability, so everyone refers to the same flaw.

The CVE record only identifies the issue. Severity and details usually come from databases such as the NVD, which assigns a CVSS score from 0 to 10.

A CVE ID is not a risk rating by itself. Always read the affected version range and the score.

A CVE is reserved, published once there is a disclosure or fix, and sometimes updated later with a revised score. Many open source flaws appear in ecosystem advisories before the NVD finishes its analysis, which is why tools combine several sources.

Dual licensing means the same code is offered under two licenses. There are two common patterns.

• Open plus commercial: a copyleft license for the community and a paid license for companies that cannot accept copyleft. MySQL and Qt have used this model.
• Choice of open licenses: an MIT OR Apache-2.0 style expression where you pick the one you like, common in Rust crates.

In compliance, an OR expression lets you select the more convenient license, while AND means you must satisfy both.

Check which license applies to what you actually received. Some projects offer the commercial option only by contract, and the owner usually needs contributor agreements to relicense. If you rely on the open option, you carry its obligations in full.

The MIT License is very short. When you copy or distribute the software, you must include the original copyright notice and the permission notice in all copies or substantial portions.

The software is provided "as is" with no warranty, so the author is not liable for problems. There is no duty to publish your own source code and no patent clause.

In practice you meet the obligation by bundling the license text into your third-party notices file or attribution report.

The related ISC license is functionally similar, and BSD-3-Clause adds a rule against using the author's name to endorse your product. Nothing in MIT lets you remove the original copyright line, even if you modify the code.

Two licenses are compatible if code under each can be combined into one work and you can still satisfy both at the same time. If their conditions conflict, the combination cannot be legally distributed.

Direction matters. MIT code can go into a GPL project, because GPL's terms can be applied to the result. GPL code placed inside an MIT project makes the combined work effectively GPL, which defeats the MIT choice.

This is why tools check not only each license but how the components are combined and shipped.

Real pairs help here: Apache-2.0 and GPL-3.0 are compatible, Apache-2.0 and GPL-2.0-only are not, and EPL-2.0 conflicts with the GPL unless a secondary license is declared. Tools can show a matrix, but borderline cases still need legal review.

They mostly describe the same licenses from different viewpoints.

Almost every popular license, such as GPL, MIT and Apache-2.0, qualifies as both. The split matters mainly in philosophy and wording, which is why people write FOSS to cover both.

For a compliance team, neither label tells you the actual obligations. You still need the exact license text, and the right comparison is license by license, not label by label.

Both are ways to confirm that a contributor has the right to submit code.

A Contributor License Agreement (CLA) is a signed agreement where the contributor grants the project owner rights to the contribution. It can make later relicensing easier for the owner.

A Developer Certificate of Origin (DCO) is lighter. The contributor adds a Signed-off-by line to each commit, which certifies they can contribute it under the project license. The Linux kernel uses this.

git commit -s -m "Fix parser bug"

Compliance teams care because a project with a CLA can change its license later, as several vendors have done, while a DCO-only project needs agreement from every contributor to relicense. That affects how stable a dependency's license is over time.

The CLI walks the directory tree, looks for known manifest and lock files, and picks an analysis strategy for each ecosystem it recognizes. Each strategy produces a dependency graph with direct and transitive packages.

The graph is uploaded with revision details. The server then resolves each package to its license text and checks vulnerability data.

Where manifests are missing, the CLI cannot invent them. Unusual layouts may need targets configured or entries in fossa-deps.yml. In monorepos the CLI reports one target per manifest, so you can see which service pulls in which package.

A manifest usually holds version ranges, such as "express": "^4.18.0". That could resolve to many versions. The lockfile records the exact versions that were installed, including transitive ones.

Without a lockfile, a scanner must guess or re-resolve at scan time, and the result may differ from what you shipped last month. A license change or a CVE in a newer patch could be missed or wrongly reported.

Commit your lockfile and scan it so the report matches the real build.

Ecosystems differ. Go modules and Cargo record exact versions, while Maven projects usually resolve at build time, so a strategy that reads the resolved tree is more accurate than the pom alone. Review lockfile changes in pull requests like any other code.

This describes how the CLI resolves a dependency graph.

The CLI tries the best available strategy per project and falls back to a simpler one when a tool is missing. This is why a CI image without the build tool can quietly lower accuracy.

When two scans differ, check which strategy ran. Document which build tools must exist in CI, and add them to minimal containers if needed so analysis stays accurate.

Store the API key as a CI secret, install the CLI, run analyze on each push and pull request, then run test as the gate.

- name: Install FOSSA CLI
  run: |
    curl -H 'Cache-Control: no-cache' https://raw.githubusercontent.com/fossas/fossa-cli/master/install-latest.sh | bash
- name: Analyze
  run: fossa analyze
  env:
    FOSSA_API_KEY: ${{ secrets.FOSSA_API_KEY }}
- name: Policy check
  run: fossa test
  env:
    FOSSA_API_KEY: ${{ secrets.FOSSA_API_KEY }}

Pin the CLI version in production pipelines instead of always taking the latest, so builds stay reproducible.

Run analyze on the default branch after each merge too, not only on pull requests. That keeps the dashboard current, so a newly published CVE in an existing dependency still shows up when nobody is touching the code.

The GPL is triggered by distribution. A company running modified GPL code on its own servers never distributes it, so it owes nothing. AGPL-3.0 closes that gap with Section 13.

If you modify an AGPL program and let users interact with it over a network, you must offer those users the corresponding source of your modified version.

Embedding AGPL code in a hosted product can therefore force you to publish your changes, and possibly more depending on how tightly it is combined. Using an unmodified AGPL service as a separate component is usually lower risk but still needs legal review. Many companies simply deny AGPL in policy.

A common mitigation is to avoid AGPL in anything customer-facing or to buy the vendor's commercial license. Also ask whether your use counts as modification. Even running an unmodified AGPL server is a question legal teams like to answer explicitly.

Both are copyleft, but they differ in reach.

With LGPL, dynamic linking is the easy path. Static linking is possible but requires giving users a way to relink. Changes you make to the LGPL library itself must still be shared.

The key LGPL question is how the library is linked and whether users can swap it. On mobile or embedded platforms with static linking and locked firmware, LGPL can be harder to satisfy than it looks.

The FSF's view is that Apache-2.0 has terms, mainly the patent termination clause and certain indemnity-style conditions, that count as extra restrictions under GPLv2. GPLv2 does not allow adding restrictions, so the two cannot be merged.

GPLv3 was drafted to be compatible with Apache-2.0, so Apache code can go into a GPLv3 project.

• Apache-2.0 into GPL-3.0-only: fine.
• Apache-2.0 into GPL-2.0-only: not fine. The Linux kernel is an example.
• Apache-2.0 into GPL-2.0-or-later: fine by choosing v3.

Read the exact SPDX string. GPL-2.0-or-later is easy, since you may take version 3. GPL-2.0-only is the sticking point, and it covers plenty of older code, including the Linux kernel itself.

Vendored code is a library whose source was copied into your repo, so no package manager knows about it. A normal scan misses it, which is a common compliance gap.

Declare it in fossa-deps.yml under vendored-dependencies with a name and path. FOSSA then scans that folder for license text and headers and records the result as a dependency.

vendored-dependencies:
  - name: libfoo
    path: third_party/libfoo

If you know the upstream package and version, a referenced-dependencies entry is more precise.

Typical causes are copied helper files, libraries forked and patched in place, and C code under third_party. Record the version you copied and any local patches, since vendored code still carries its license and any upstream vulnerability.

Use the container subcommand with an image name or a saved tarball. The CLI inspects the image layers, reading OS package databases such as dpkg, apk or rpm, plus application dependencies found inside.

fossa container analyze ubuntu:22.04
fossa container test ubuntu:22.04

This matters because the base image brings in hundreds of packages and licenses your source repo never mentions. Run it in CI after the image build and before you push to a registry.

Base image choice matters. A slim or distroless image carries far fewer packages, and so fewer licenses and CVEs, than a full OS image. Rebuild regularly, because a scan reflects the image at that moment and base layers go stale.

Both are SBOM formats, but they started with different goals.

Many organizations accept either. Choose the one your customers or regulators ask for, and pick a tool that can export both.

CycloneDX supports VEX statements, which let you say whether a product is actually affected by a CVE and cut noise when handing an SBOM to customers. SPDX 3.0 widened its scope with profiles for security and AI as well.

Under copyright law, work without a license is all rights reserved. You have no permission to copy, modify or distribute it. Being public on GitHub does not change that, because the platform terms only allow viewing and forking.

FOSSA reports this as an unlicensed or unknown license issue. Typical next steps:

1. Look for a LICENSE file, a README note or file headers.
2. Ask the maintainer to add a license.
3. Replace the package with a licensed alternative.
4. Get written permission if you must keep it.

A LICENSE file in the repo root does not always cover every subfolder, because bundled sub-projects can carry their own terms. When a project is abandoned there is nobody to ask, which is another reason to replace it.

After the CLI uploads your dependency graph, the server matches each package name and exact version against vulnerability data, including the NVD and ecosystem advisories.

Each finding shows the CVE, a CVSS score, the affected version range and, where known, the version that fixes it.

Matching is by version, not by whether your code calls the vulnerable function. That is why some findings are real exposure and some are noise, and why triage matters.

A fixed version is a hint, not a guarantee, so test the upgrade. Where no fix exists, options include a workaround from the advisory, a patched fork, or removing the feature that uses the package.

A raw CVSS score is a starting point, not the answer. Rank by real exposure:

1. Is it on the CISA Known Exploited Vulnerabilities list or showing a high EPSS probability?
2. Is the vulnerable function reachable from your code?
3. Is the component internet-facing or only in an internal tool?
4. Does it ship to production or only run in tests?
5. Is a fixed version available?

A medium CVSS flaw in an exposed, actively exploited library often beats a critical one in an unused dev dependency.

Set response targets by severity and exposure, for example exploited criticals within days and highs within a few weeks, and track them. Bots can open upgrade pull requests, but people decide on risk acceptance.

Ignore an issue only with a reason you can defend and write down. Good cases are:

• A confirmed false positive, such as a misidentified license.
• A vulnerable function you have proven is never reachable.
• A component used only at build time and never shipped.
• A formally accepted risk, ideally with an expiry or review date.

Record who approved it and why. Do not ignore something just because the fix is inconvenient, and review ignored items when the product or its usage changes.

Add time limits where the tool allows. An ignore for an unreachable function can become wrong when a refactor starts calling it, so tie reviews to releases or dependency changes.

Test fixtures, examples and docs folders often contain their own manifests, which add noise and false violations. Exclude them in .fossa.yml or on the command line.

# .fossa.yml
paths:
  exclude:
    - ./test/fixtures
    - ./examples

# or inline
fossa analyze --exclude-path ./test/fixtures

Be careful not to exclude any folder whose code ships. Review exclusions in code review so they do not quietly hide real dependencies.

Targets can also be narrowed with only rules, handy in monorepos when a pipeline should scan just one service. Keep the exclusion list short and explain each entry with a comment.

An old codebase may carry hundreds of legacy issues. Failing every PR on all of them blocks teams. The --diff option compares a revision against a base and reports only the issues the change introduces.

fossa analyze --revision $BASE_SHA
fossa analyze --revision $PR_SHA
fossa test --diff $BASE_SHA

Both revisions must be analyzed first. The result is a PR gate that stops new problems while the legacy backlog is cleaned up separately.

Pair it with a scheduled full scan on the main branch so legacy issues stay visible and planned rather than hidden. If the base revision was never analyzed there is nothing to compare against, so analyze it first.

Manifest scanning only sees declared dependencies. Snippet scanning looks for fragments of open source code that were copied directly into your files, such as a pasted function from a repo or a forum answer.

It works by fingerprinting your code and comparing the fingerprints to an index of known open source. It has become more relevant as AI coding assistants can produce text that matches existing licensed code.

Limits: tiny or very common snippets give false positives, and not every tool or plan includes it, so verify availability. Note that Stack Overflow content is licensed CC BY-SA, which has its own attribution rules.

If a match is real, you can comply with the license, rewrite the code independently, or use the original library properly. Record the outcome so the same snippet is not flagged again and again.

License detection reads metadata and file text, and both can mislead.

• Wrong metadata: a package declares MIT in its manifest but ships a GPL file inside.
• Modified text: a custom or edited license that matches no known template.
• Multiple licenses: different folders under different terms.
• Declared vs. concluded: what the author states may not match what the files actually say.

Treat tool output as strong evidence, not a legal conclusion. Send unclear or high-risk findings to legal review and record the decision.

To improve accuracy, check the license file of the exact version you use, prefer SPDX-tagged metadata, and record manual overrides with a source link. Re-verify any override when the package upgrades.

Start with a simple loop and assign clear owners.

flowchart LR
  A["Inventory components"] --> B["Classify licenses"]
  B --> C{Policy check}
  C -- Allowed --> D["Ship with notices"]
  C -- Flagged --> E["Legal and engineering review"]
  E --> D
  C -- Denied --> F["Replace or remediate"]
  F --> A
  D --> G["Monitor new versions and CVEs"]

Engineering runs scans in CI, legal sets policy and reviews exceptions, and security watches vulnerabilities. Many teams model their program on OpenChain (ISO/IEC 5230), which defines what a good program contains.

Keep the process light enough that engineers actually use it. Let automation handle clear cases such as MIT and Apache-2.0, and send only unusual ones to people. Train developers on the basics and keep an approval record for audits.

Pinning fixes the exact version you build with, so the code you tested is the code you ship. Floating ranges can silently pull in a new release.

That new release might change its license, introduce a bug, or in the worst case be a malicious publish. Pinned and hashed installs make audits and rollbacks predictable.

Pins need upkeep, so pair them with an update bot such as Dependabot or Renovate.

Hash checks add a layer: if a registry artifact is altered, the install fails instead of quietly accepting it. A private mirror also protects against sudden package removals, like the left-pad incident in 2016.

In an acquisition, the buyer wants to know what open source the target depends on and whether that creates liability.

1. Request an SBOM or scan the codebase with a tool like FOSSA.
2. Check for copyleft code in products that are distributed.
3. Look for unlicensed code, conflicts and undeclared snippets.
4. Review known vulnerabilities in shipped components.
5. Set remediation tasks and contract terms.

Findings can change the price, add warranty clauses, or become conditions to closing. A clean, documented history from continuous scanning makes this review much faster.

On the seller's side, early preparation helps: keep an SBOM per release, a record of license decisions and a list of exceptions. Buyers value clear evidence more than a perfect zero-issue report.

Pick the option that fits how the component is used.

Whatever you choose, record the decision so the next scan does not reopen the same question.

Do not rely on isolation unless the boundary is real. Separate processes using a documented interface differ from sharing memory and data structures. For anything shipped to customers, get legal confirmation before leaning on this argument.

A license is attached to a version, not to the project forever. Maintainers can move future releases to a different license while older ones stay as they were.

Examples include Elasticsearch moving away from Apache-2.0 in 2021 and HashiCorp moving its products to the Business Source License in 2023. A routine upgrade could silently take you from an allowed license to a restricted one.

Re-scan on every dependency update. A good policy check will flag a changed license on upgrade, and that is a reason to hold on a safe older version or plan a switch.

Forks often follow license changes. OpenTofu forked Terraform after HashiCorp's change, and OpenSearch forked Elasticsearch after its change. Teams that depend on such projects often move to the fork to keep an OSI-approved license.

The command runs locally first, then hands off to the server.

sequenceDiagram
  participant Dev as Developer or CI
  participant CLI as FOSSA CLI
  participant Srv as FOSSA server
  Dev->>CLI: fossa analyze
  CLI->>CLI: discover targets and manifests
  CLI->>CLI: run strategies and build dependency graph
  CLI->>Srv: upload graph with project and revision
  Srv->>Srv: resolve licenses and match vulnerabilities
  Dev->>CLI: fossa test
  CLI->>Srv: poll until scan completes
  Srv-->>CLI: issues based on policy
  CLI-->>Dev: exit code 0 or non-zero

The CLI sends the dependency graph and metadata, not your whole source tree, and the heavy license and vulnerability work happens on the server.

Some details help in interviews. The revision is usually the git commit SHA, the project name and branch decide where results appear, and analyze can run many times for different revisions. Failure at analyze usually means discovery or tooling problems, while failure at test means policy problems.

Work from the outside in.

1. Run fossa list-targets to see whether the project was discovered at all.
2. Confirm the lockfile is committed and the path is not excluded in .fossa.yml or by --exclude-path.
3. Re-run with --debug and read the log for strategy warnings, such as a missing build tool.
4. Check that the CI image has the needed toolchain, since a dynamic strategy can fail there but work on your laptop.
5. Compare the revision in the dashboard with the commit you expected.
6. As a last resort, add the package to fossa-deps.yml.

Most cases end up being an exclusion, an uncommitted lockfile or a missing tool in CI.

Keep a short checklist in your team docs. Many teams also add a CI step that fails when fossa list-targets returns nothing, which catches silent breakage after a repo restructure.

Log4Shell is CVE-2021-44228, a critical remote code execution flaw in Apache Log4j 2, disclosed in December 2021 with a CVSS score of 10.0. A crafted string in a logged message could trigger a JNDI lookup that loaded attacker-controlled code.

Affected versions ran from 2.0-beta9 up to 2.14.1. Version 2.15.0 was the first fix, and 2.16.0 and 2.17.0 followed to close related problems.

It matters because Log4j was usually a transitive dependency, buried inside other products. Teams without an inventory spent days just finding where it ran, and that made the case for SBOMs and continuous dependency scanning.

Mitigations at the time included upgrading to a fixed version or removing the JndiLookup class from the jar as an emergency workaround. Scanning tells you where Log4j lives, and the fix is then applied per application.