OSS 101

Software whose source code is public and may be viewed, modified and distributed by anyone, subject to its license. Modern applications draw 70%+ of their code from open source components.

The practice of protecting software from tampering and attack across development, build, distribution and runtime — covering source code, third-party components, build systems, artifact registries and delivery channels. SolarWinds and Log4Shell made it a security priority.

A Software Bill of Materials: a complete inventory of every component, version and dependency in a piece of software — its 'ingredients list'. US EO 14028 and the EU CRA both require SBOMs.

Software Composition Analysis: automatically identifying open source components in code and detecting known vulnerabilities and license risks. CleanSource SCA identifies down to snippet level, across direct and transitive dependencies.

Direct dependencies are components you explicitly declare; transitive dependencies are what those components pull in themselves. Most vulnerabilities hide in transitive dependencies — typically over 80% of the tree.

Broadly permissive (MIT, Apache-2.0, BSD — few obligations, business-friendly) and copyleft (the GPL family — derivatives must be released under the same terms). Check obligation strength before adopting.

Derivative works built on GPL components must be open-sourced under GPL when distributed, with complete source provided — the 'viral' effect. Internal use without distribution generally does not trigger obligations.

LGPL is looser: dynamic linking generally doesn't require your code to be open-sourced. AGPL is stricter: serving over a network counts as distribution, so SaaS triggers the obligations too.

Two components' license terms are mutually incompatible and cannot legally coexist in one work — classically GPLv2 vs Apache-2.0. Detection needs tooling at the dependency-combination level.

The international standard for open source compliance management (ISO/IEC 5230), defining key requirements for enterprise compliance programs. Certification demonstrates capability up and down the supply chain.

Yes — nearly all commercial software does. The key is identifying each component's license obligations and fulfilling them: retain copyright notices, provide license texts, and open-source what the terms require.

Common Vulnerabilities and Exposures: the global numbering system for known security flaws, e.g. CVE-2021-44228 (Log4Shell). Maintained by MITRE, it is the lingua franca of vulnerability intelligence.

The Common Vulnerability Scoring System quantifies severity from 0-10: 9.0-10.0 critical, 7.0-8.9 high, 4.0-6.9 medium. It factors attack vector, complexity, required privileges and user interaction.

CWE classifies weakness types (e.g. CWE-78 command injection) — 'what kind of mistake'. CVE numbers concrete vulnerability instances — 'which flaw in which product'. A CVE typically maps to one CWE.

Attackers publish malicious components to public registries (npm, PyPI), luring developers via typosquatting or hijacked maintainer accounts to steal credentials or plant backdoors. Monthly events regularly exceeded one hundred in early 2026.

Attackers register public packages with the same names as a company's internal private packages at higher versions, tricking build tools into pulling the malicious public copy. Defend with private-registry priority and version pinning.

A 0-day is exploited before an official patch exists — hardest to defend. An N-day has a patch published N days ago but targets remain unpatched — most real attacks are N-day, so remediation speed is what matters.

Shifting security left and automating it throughout DevOps: SAST at coding, SCA at dependency intake, DAST in testing, monitoring at runtime — so security and delivery speed coexist instead of competing.

SAST statically analyzes the code you write (white box); DAST attacks the running application (black box); SCA analyzes the third-party components you import. Together they cover both first-party code and external dependencies.

Add automated checks to the pipeline: SCA/SAST scans on commit, policy-based blocking (fail the build on critical vulnerabilities or banned licenses), results fed back into code review. Tier the gate policy — a blanket block kills delivery.

The enterprise practice of managing open source use: intake review, component inventory (SBOM), vulnerability response, license compliance and upgrade strategy — so usage is safe, traceable and obligation-compliant.

Start with a review board and evolve toward automated gates: define intake criteria (license allowlist, maintenance activity, vulnerability threshold), integrate into the dependency workflow, and periodically rescan the existing estate.

Both are mainstream SBOM standards. SPDX (Linux Foundation, an ISO standard) models license compliance in finer detail; CycloneDX (OWASP) grew from security use cases and iterates fast. Most tools support both — choose per downstream requirements.

Models and datasets become components themselves (and can be poisoned), fast-moving AI frameworks ship dense vulnerabilities, and agent plugin/tool mechanisms open code-execution surfaces. Since 2026, AI components lead critical-vulnerability counts.

Hiding malicious instructions inside content an AI processes (web pages, documents, tickets) to make the model take unauthorized actions — leaking credentials or invoking dangerous tools. One of the top attack vectors for LLM apps (CWE-1427).

Toolchain command injection, unauthenticated endpoints, plaintext credential storage, malicious skill/plugin poisoning and sandbox escape. Mitigate with tool allowlists, least privilege, default authentication — and capability audits with tools like SkillSec.