CM-10(1): Open-source Software

CM-10(1) requires you to set and enforce explicit restrictions on open-source software (OSS) use in your environment, then prove those restrictions operate in practice. To operationalize it quickly, define what OSS is allowed, under what conditions, who can approve exceptions, and how you detect and stop unapproved OSS from entering builds, images, endpoints, and production. ¹

Key takeaways:

• Write enforceable OSS restrictions (allowed/prohibited categories, approval gates, and exception handling), not a generic “OSS policy.” ¹
• Implement technical controls that prevent unapproved OSS from entering code and runtime, and keep auditable logs showing the controls work. ¹
• Retain evidence that ties decisions to inventories (SBOM/component lists), scanning results, and approvals across the SDLC and operations. ¹

CM-10 is the NIST “Software Usage Restrictions” control family, and CM-10(1) focuses specifically on open-source software. The operative word is “restrictions.” Your assessor will look for a defined set of constraints that narrow how OSS can be selected, introduced, and operated, plus proof those constraints are enforced across engineering and IT operations. ¹

This requirement shows up in federal information systems and contractor environments handling federal data, where OSS is common but unmanaged OSS intake creates supply chain and licensing risk. You do not need to ban OSS to satisfy CM-10(1). You need to decide what “acceptable OSS” means for your mission and risk tolerance, then implement controls that keep your actual environment aligned with that decision. ¹

Practically, the fastest path is to: (1) define a restrictive-but-usable OSS standard, (2) wire it into software intake and CI/CD, (3) add monitoring at runtime, and (4) build an evidence set that maps approvals and exceptions to what’s deployed. Tools can help, but this control is won or lost on enforceable rules and repeatable evidence.

Regulatory text

NIST CM-10(1): Open-source Software — “Establish the following restrictions on the use of open-source software: {{ insert: param, cm-10.01_odp }}.” ¹

Operator interpretation: NIST expects you to define your OSS restrictions explicitly (the organization-defined parameters are where you specify your restrictions), then implement them as real gates and checks. Your restrictions must be specific enough that a reviewer can test them against a sample of repos, builds, images, endpoints, or procurement records and reach a clear pass/fail outcome. ¹

Plain-English interpretation (what CM-10(1) is asking for)

You must control OSS the same way you control any other software: approved sources, approved versions, known vulnerabilities handled, and approved legal terms. “Restrictions” should answer four questions:

1. What OSS is allowed? (e.g., approved licenses, approved ecosystems, approved registries)
2. What OSS is prohibited? (e.g., certain licenses, unmaintained packages, unknown provenance)
3. How does OSS get approved? (who, criteria, workflow, exceptions)
4. How do you block and detect noncompliant OSS? (CI/CD, artifact repositories, endpoint controls, runtime monitoring)

Who it applies to

Entities: Federal information systems and contractor systems handling federal data. ¹

Operational context: This is most relevant where any of the following are true:

• You build software (internal apps, microservices, scripts, IaC).
• You deploy third-party applications that bundle OSS components.
• You run container platforms where base images embed OSS.
• You allow developers/admins to install packages from public registries.

Functions that must participate: Engineering, DevOps/platform, IT operations, security (AppSec/product security), legal/procurement (license terms), and the system owner accountable for NIST control compliance.

What you actually need to do (step-by-step)

Step 1: Define your OSS restriction set (policy + standard)

Create an “OSS Use Standard” that is testable. Minimum components:

• Definition of OSS in scope (code, libraries, packages, container images, OS packages, embedded firmware components).
• Allowed sources (approved package registries, approved Git hosting orgs, approved artifact repositories).
• License rules (licenses allowed without review, licenses requiring legal review, licenses prohibited).
• Security rules (requirements for vulnerability scanning, patch timelines as internal targets, and criteria for blocking releases).
• Maintenance/provenance rules (minimum signals like active maintainers, signed releases where feasible, pinned versions, checksum verification).
• Exception process (who approves, required justification, time-bound exceptions, compensating controls).
• Scope statement (which systems must comply: production, CI runners, build images, endpoints).

Deliverable: a short standard (2–5 pages) plus a one-page summary engineering can follow.

Step 2: Build an approval workflow that matches how software is acquired

Your restrictions are only enforceable if they align to your intake paths:

• Engineering intake: new dependency request, new base image request, new toolchain component request.
• IT/admin intake: desktop tools, scripts, packages installed on servers, golden images.
• Third-party intake: vendor/third-party applications or SaaS where OSS is embedded (contractual OSS disclosure clauses can help, but keep it practical).

Implementation pattern:

• Route “new OSS component” requests through a ticketing workflow with required fields: component name, version, source URL/registry, license, intended use, data sensitivity context, and whether it will run in production.
• Assign decisioning to AppSec for security criteria and to legal/procurement for license criteria where needed.
• Record outcomes: approved, approved with conditions, denied, exception granted (time-bound).

Step 3: Enforce restrictions in CI/CD and build systems

Add hard stops where OSS enters your environment:

• Dependency scanning in CI: fail builds that include prohibited licenses or dependencies from unapproved sources; require pinned versions.
• Artifact repository controls: require dependencies to be pulled through an internal proxy/repository; block direct pulls from public registries except via approved paths.
• Container controls: allow only approved base images; scan images for known vulnerable packages; block images that violate your OSS rules before they reach production.
• SBOM generation: generate an SBOM (or component inventory) for each release artifact and store it with the build record for traceability.

Your goal is simple: a developer should not be able to ship OSS that violates your restrictions without leaving an auditable exception trail.

Step 4: Enforce restrictions in runtime and endpoint environments

CI gates are necessary but not sufficient if teams can “curl | bash” on servers or install ad hoc packages:

• Server/endpoint software restriction: limit who can install software, restrict package managers, and enforce golden images where possible.
• Configuration management: ensure only approved repos and package sources are configured on hosts.
• Runtime monitoring: detect drift (new packages, new binaries, new containers) and reconcile against approved inventories.

Step 5: Create recurring review and accountability

Operationalize ownership:

• Name a control owner (often AppSec or GRC) and a technical owner (platform/DevOps).
• Review exceptions and high-risk OSS periodically and close expired exceptions.
• Sample-test repos and deployed workloads to verify the restrictions are working and produce evidence.

If you use Daydream to manage your control library, map CM-10(1) to a named owner, a written procedure, and a recurring evidence checklist so assessors see consistent operation, not a one-time policy exercise. ¹

Required evidence and artifacts to retain

Keep evidence that shows both design (what you require) and operation (proof it happened):

Design artifacts

• OSS Use Standard / OSS Restrictions document (version-controlled).
• Secure SDLC/AppSec standards referencing OSS gates.
• Exception procedure and approval matrix (RACI).

Operational artifacts

• Dependency approval tickets (samples) with decisions and conditions.
• CI/CD logs showing dependency/license policy checks and build failures when rules are violated.
• Artifact repository configuration showing approved sources and blocked external pulls where applicable.
• SBOMs or component inventories for releases (stored with build artifacts).
• Container image scan reports and admission/allow-list configurations (where used).
• Exception register with start/end dates and compensating controls.
• Internal audit or continuous control testing results demonstrating compliance.

Evidence should be easy to sample: “show me one recent release and prove every OSS component complied or had an approved exception.”

Common exam/audit questions and hangups

Assessors tend to probe:

• “Show the actual restrictions. Where are they written, and how do engineers follow them?” ¹
• “How do you prevent unapproved OSS from entering production?”
• “How do you know what OSS is in your environment today?” (inventory/SBOM expectation)
• “How do you handle OSS embedded in third-party products?”
• “Show exceptions and prove they are controlled and time-bound.”

Hangups that delay audits:

• Restrictions are too high-level (“scan dependencies”) without pass/fail criteria.
• No linkage between policy and actual enforcement points.
• Evidence exists but is scattered across tools with no control narrative tying it together.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating OSS as only a legal/license issue.
   Fix: Make restrictions cover provenance, security scanning, and operational enforcement, not just licenses.

2. Mistake: Relying on “developer guidance” instead of hard gates.
   Fix: Put checks in CI/CD and artifact pipelines. Add an exception path so teams don’t bypass controls.

3. Mistake: No inventory, no traceability.
   Fix: Store SBOMs or dependency manifests per build; keep a register of approved components and exceptions.

4. Mistake: Ignoring ops-installed OSS.
   Fix: Include servers, golden images, and admin tooling in scope. Restrict package sources and permissions.

5. Mistake: Exceptions become permanent.
   Fix: Require an expiration date and compensating controls; review and close or renew with justification.

Risk implications (why auditors care)

Unrestricted OSS use increases the chance of:

• Introducing vulnerable or malicious dependencies through public registries.
• Losing control of what is running in production because components shift over time.
• Licensing conflicts that create contractual or distribution obligations.
• Failing incident response because you cannot quickly identify affected components.

CM-10(1) is the control that forces “OSS intake discipline” into normal engineering operations, with evidence that discipline is real.

Practical 30/60/90-day execution plan

First 30 days (Immediate foundation)

• Assign control owner and technical owner; define scope (systems, repos, build pipelines).
• Draft OSS restriction set: allowed/prohibited sources, licenses, and minimum security/provenance requirements. ¹
• Stand up an exception register and a single intake workflow (ticket template) for new OSS components.
• Identify top intake paths (CI/CD, containers, endpoints) and document where enforcement will occur.

Days 31–60 (Enforcement in the build path)

• Implement CI checks for dependency source and license rules; set initial enforcement to “warn,” then move to “block” for the highest-risk violations.
• Route dependencies through an internal artifact repository or proxy where feasible; document controls.
• Generate SBOMs/component inventories for build artifacts and store them with release records.
• Run a pilot on a small set of critical repos/services; collect evidence samples for assessors.

Days 61–90 (Runtime/ops coverage + assessment readiness)

• Extend restrictions to container base images and deployment admission where applicable.
• Add controls for ops-installed software: repository allow-lists, golden images, and drift detection.
• Perform a control self-assessment: sample releases, map components to approvals/exceptions, and confirm logs are retained.
• Produce an auditor-ready evidence pack: policy/standard, procedures, sample tickets, CI logs, SBOMs, exception register.

Frequently Asked Questions

Do we have to ban open-source software to meet cm-10(1): open-source software requirement?

No. CM-10(1) requires restrictions, not a blanket prohibition. Your restrictions must be explicit and enforceable, with evidence that you prevent or control noncompliant OSS. ¹

What counts as “open-source software” for this control?

Treat OSS broadly: libraries, packages, container base images, OS packages, scripts, and embedded components. Define your scope in the OSS Use Standard so assessors can test it consistently. ¹

How do we handle OSS inside a third-party product or SaaS?

Put it in your third-party intake: require OSS disclosure where feasible, or require SBOMs/component attestations for higher-risk products. Track the decision and any exceptions the same way you do for internal dependencies.

What evidence is most persuasive to an auditor?

A tight chain from written restrictions to enforcement logs. Show a release with its SBOM/component list, the CI policy results, and the approval/exception record for any flagged components. ¹

Who should approve OSS exceptions?

Assign approval based on the risk dimension: AppSec for security risk, legal/procurement for license risk, and the system owner for mission acceptance. Record approvals, compensating controls, and an expiration date.

We already scan for vulnerabilities. Is that enough?

Scanning helps, but CM-10(1) expects “restrictions,” which usually includes allowed sources, license rules, and controlled intake. Add gating and approvals so scans translate into enforced decisions. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON