Don't let hidden code
trigger an export violation

Controlled crypto, restricted contributors, and missing SBOMs stop shipments, trigger investigations, and block deals.
SCANOSS makes the risk visible before it reaches the border.

0 M

the largest corporate penalty in years. A single export to the wrong end user. ^[1]

0 %

of UK export licences for non-military items were for software. ^[2]

0 %

of EU dual-use trade is cryptographic software — the most scrutinised category. ^[3]

Export controls don't care what your team intended.

Hidden crypto, restricted contributors, and incomplete SBOMs create exposure that reviews miss until it’s too late. SCANOSS detects controlled algorithms, flags risky origins, and generates audit-ready SBOMs and CBOMs automatically.

Make export reviews repeatable, evidence‑based, and fast.

The classification problem

Most violations start with a misclassification, not a decision.
Software companies routinely create export exposure without knowing it. These are the four failure modes that trigger enforcement — and how SCANOSS addresses each one.

"We don't export software"

If your code is downloaded abroad, transferred to overseas developers, or accessed by foreign nationals in your own office, you are exporting under the EAR, whether or not a physical shipment takes place. Deemed exports are real, and they are enforced.

SCANOSS maps contributor geography so you know exactly where your code is going and who has touched it.

"We only use open source encryption"

Under BIS rules, incorporating open source encryption creates a new controlled item that must be classified, typically under ECCN 5D002, which requires export authorisation to nearly every country in the world.

SCANOSS detects cryptographic functions at snippet level, including those inherited through open source dependencies.

"We qualify as mass market"

Mass market treatment under the EAR removes most export restrictions — but it has strict criteria, and many SaaS products don’t meet them. Companies that assume mass market status without a formal analysis are sitting on an unexamined classification risk.

SCANOSS provides the cryptographic inventory needed to support a defensible classification decision.

"We have a licence exception"

License Exception ENC covers most encryption exports — but applying the wrong subparagraph, skipping the self-classification report, or missing a BIS filing requirement turns a valid exception into a violation.

SCANOSS generates the CBOM and provenance documentation that makes ENC analysis and annual reporting tractable at scale.

Key regulations

The six frameworks shaping software export today.

EAR

U.S. Export Administration Regulations

Software containing unclassified strong cryptography may require a licence before leaving the US.

ITAR

International Traffic in Arms Regulations

Defence-adjacent software — including components tied to military use or certain encryption — falls under ITAR. Violations carry criminal liability, not just fines.

EU Dual-Use Regulation

U.S. Export Administration Regulations

Software with strong crypto may require an export licence to leave the EU. The regulation applies regardless of whether the export is commercial or incidental.

DORA

EU Digital Operational Resilience Act

Not an export law, but directly relevant. Financial services firms must demonstrate software supply chain resilience to regulators and auditors. That means maintaining a full component inventory.

EO 14144/EO 14036

U.S. Cybersecurity Executive Orders

Federal suppliers must demonstrate software supply chain security. The mandate has evolved under successive administrations, but SBOM readiness and software self-attestation remain practical requirements for government contract eligibility.

CRA

EU Cyber Resilience Act

Mandatory SBOMs and vulnerability management for software sold in the EU. Gaps here affect whether your software is considered fit for cross-border trade.