CM-7(8): Binary or Machine Executable Code

CM-7(8) requires you to block binary or machine-executable code from sources that provide limited or no warranty, or that do not provide source code. Operationally, you implement this by defining “approved executable sources,” enforcing allowlisting and code provenance checks, and routing exceptions through a documented risk decision and compensating controls. ¹

Key takeaways:

• Define what “binary or machine-executable code” means in your environment and restrict it to approved, supportable sources with source-code availability.
• Enforce the rule with technical controls (application allowlisting, repository controls, CI/CD gates) plus procurement/third-party terms.
• Keep assessor-ready evidence: an executable allowlist, exception decisions, and proof of enforcement across endpoints and build pipelines.

The cm-7(8): binary or machine executable code requirement is easy to misunderstand because teams hear “no binaries without source” and assume it only applies to open source. In practice, CM-7(8) is a supply chain control: you are reducing the chance that unknown or unsupported executable code enters production, endpoints, or build pipelines where it can execute with high privilege and limited accountability.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalization is to treat CM-7(8) as a policy-backed restriction plus an enforcement pattern. You set a default prohibition on executables from low-assurance sources (limited/no warranty, or no source code), define a narrow set of permitted sources (commercially supported software, internally built artifacts, and vetted components), and require exceptions to be explicit risk decisions with compensating controls.

This page translates the requirement into implementable steps: scope, decision criteria, procurement and engineering workflow changes, technical guardrails, and the evidence an auditor will ask for. The goal is to make “what’s allowed to execute” provable, repeatable, and reviewable.

Regulatory text

NIST CM-7(8) excerpt: “Prohibit the use of binary or machine-executable code from sources with limited or no warranty or without the provision of source code; and” ¹

What the operator must do:
You must prevent installation, execution, or deployment of executable artifacts when (a) the source offers limited or no warranty/support, or (b) source code is not provided/available for your review, escrow, or other assurance purposes. In operational terms, you need (1) a clear definition of prohibited sources, (2) a mechanism to enforce the prohibition, and (3) a controlled exception process that documents risk acceptance and compensating controls. ¹

Plain-English interpretation (what this means)

CM-7(8) is about trust and accountability for code that can run. “Binary or machine-executable code” includes things like compiled applications, installers, agent software, container images, VM images, firmware blobs, scripts run with an interpreter, and CI/CD-delivered artifacts.

Two red flags trigger the prohibition:

1. Limited/no warranty: the provider will not stand behind the software (no support, unclear liability, abandonware).
2. No source code provision: you cannot obtain source in a way that supports assurance (review, rebuild, escrow, or a verified internal copy).

You do not have to ban all third-party software. You do have to make executable intake intentional: approved channels, known publishers, contractual terms, and technical controls that stop “random binaries” from showing up on laptops, servers, or production pipelines.

Who it applies to

Entity types: Federal information systems and contractor systems handling federal data. ¹
Operational contexts where CM-7(8) bites hardest:

• Enterprise endpoints where users can install or run tools.
• Server fleets where admins can “just SCP a binary.”
• CI/CD pipelines that pull build dependencies, base images, and binaries.
• OT/IoT/firmware and drivers where binaries are common and source may be unavailable.
• Third-party delivered “appliances” and security agents that run with elevated privileges.

If you run a regulated environment mapped to NIST SP 800-53 (directly or through FedRAMP, agency ATO, or contract requirements), assume assessors will expect a defined stance on executable provenance and supportability. ²

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

1) Define scope and terms (write this down)

Create a one-page standard that defines:

• “Executable code” in your environment: PE/ELF binaries, MSI/PKG installers, container images, signed scripts, macros, etc.
• “Source provided”: what qualifies (public repo, escrow, vendor-provided source package, internally mirrored repo).
• “Limited/no warranty”: freeware with no support terms, abandoned projects, unknown publishers, “download site” binaries.

Deliverable: an “Executable Code Intake & Approval Standard” owned by Security/GRC with Engineering and Procurement sign-off.

2) Establish “approved executable sources”

Build an allowlist of sources and channels that are permitted to introduce executables:

• Internal artifact repositories (signed builds only).
• Approved commercial publishers with support terms and procurement record.
• Approved open-source projects where source is available and intake is controlled (mirrored repos, pinned versions).
• Approved container registries and base images.

Make the list operational: name the systems (repo, registry, software catalog), the owner, and the approval method.

3) Put procurement and third-party controls in front of the problem

Update third-party onboarding and procurement intake so executable software cannot be purchased/introduced without:

• Identified publisher and support/warranty terms (or documented internal acceptance of limited/no warranty).
• Source code availability statement (or documented justification why source is not available and how you mitigate).
• Security review triggers for high-privilege agents, kernel drivers, or network-facing services.

Practical mechanism: add CM-7(8) checks to your third-party due diligence questionnaire and contract checklist, then block PO/approval if the CM-7(8) fields are empty.

4) Enforce with technical guardrails (minimum viable set)

Auditors will ask “how do you prohibit it?” A policy alone rarely satisfies.

Common enforcement patterns:

• Application allowlisting on endpoints and servers for permitted executables and publishers.
• Privilege controls so users cannot install/run unapproved binaries (paired with IT-managed software distribution).
• Repository controls so builds only pull dependencies from approved registries and mirrored sources.
• CI/CD gates that require provenance signals: signed artifacts, checksums, SBOM presence, approved source origin.

Pick controls that match your architecture. The goal is to prevent “unknown executable entry,” not to create paperwork.

5) Build an exception process that is actually usable

Some binaries will be required (legacy devices, closed-source commercial products, niche drivers). CM-7(8) expects you to prohibit by default, then handle exceptions deliberately.

Your exception record should capture:

• Business justification and system scope.
• Why warranty/source is limited or unavailable.
• Compensating controls (isolation, monitoring, restricted permissions, network segmentation, runtime application control).
• Expiration/review trigger and responsible owner.

A workable approach: route exceptions through your risk register, with Security sign-off and a documented compensating control plan.

6) Monitor and prove ongoing compliance

Set up recurring review:

• Changes to the approved source list.
• New executables detected in EDR/software inventory.
• New third-party software introductions and renewals.
• CI/CD dependency and base image drift.

Daydream can help by mapping CM-7(8) to a control owner, a documented procedure, and recurring evidence artifacts so the requirement stays “green” without rework during audits. ¹

Required evidence and artifacts to retain

Keep evidence that answers three assessor questions: (1) What’s the rule, (2) how is it enforced, (3) what happened when something violated it.

Policy + governance

• Executable Code Intake & Approval Standard (current and prior versions)
• RACI: control owner, approvers, exception authorities
• Approved executable sources list (publishers, registries, repos)

Operational artifacts

• Procurement/third-party intake checklist with CM-7(8) fields completed
• Exception requests with approvals, compensating controls, and closure/review outcomes
• Software inventory outputs (endpoint/server) showing installed executables and source/publisher mapping
• CI/CD configuration evidence: approved registries, signature verification settings, build attestations if used

Technical enforcement proof

• Application allowlisting configurations and change records
• Endpoint privilege management settings relevant to software installation
• Artifact repository access controls and audit logs (who published, what, from where)
• Detection/response tickets for unauthorized executable attempts

Common exam/audit questions and hangups

“Show me how you prohibit it.”
Have screenshots/exports of allowlisting rules, repo restrictions, and a sample block event/ticket.

“What counts as limited warranty?”
Define it in your standard and show how Procurement applies it (contract terms, support SLAs, vendor terms). Keep it consistent.

“What do you do about closed-source commercial software?”
Assessors usually accept commercial binaries if there is meaningful support/warranty and controlled sourcing, plus risk-based review for high privilege. Document the rationale and controls.

“How do you control developer-installed tools?”
Expect scrutiny here. Provide a managed developer workstation approach, approved package managers/repos, and monitored exception paths.

Frequent implementation mistakes (and how to avoid them)

1. Treating CM-7(8) as a legal-only procurement clause.
   Fix: pair contract language with technical controls that stop execution from unapproved sources.

2. No definition of “executable.”
   Fix: define it broadly enough to cover scripts, containers, and firmware in your environment, then scope where enforcement applies first.

3. Exception process with no compensating controls.
   Fix: require at least one control category per exception (isolation, least privilege, monitoring, integrity checks), and document ownership.

4. Allowlist exists, but nobody maintains it.
   Fix: assign an owner and tie updates to change management and procurement intake.

5. CI/CD is ignored.
   Fix: treat build pipelines as a primary ingestion path for executable artifacts; restrict registries and require provenance checks.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should plan for assessment-driven enforcement: ATO/FedRAMP-style reviews, customer security assessments, and internal audit findings tied to software supply chain and unauthorized software controls. ²

Risk if you under-implement CM-7(8):

• Malware introduced via “free tools,” repackaged installers, or compromised download sites.
• Undocumented software that cannot be patched or supported.
• Inability to investigate incidents due to unknown provenance and lack of supplier accountability.
• Audit findings for control design gaps (“policy only”) or operating effectiveness gaps (no evidence of prevention/detection).

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Assign a control owner and approvers (Security + Procurement + Engineering).
• Publish your executable definition and prohibited source criteria.
• Inventory executable intake paths: endpoint installs, server admin processes, CI/CD dependencies, container images, firmware updates.
• Stand up an exception workflow with a template and a place to store decisions.

Days 31–60 (enforce on the highest-risk paths)

• Implement application allowlisting or equivalent runtime control on a priority fleet (admins, servers, privileged users).
• Restrict CI/CD to approved artifact repositories and registries; block direct internet pulls where feasible.
• Add CM-7(8) checks to third-party intake and procurement gates.
• Run a targeted hunt: identify top unknown publishers/executables and remediate via approval or removal.

Days 61–90 (prove it works and make it repeatable)

• Produce an assessor-ready evidence package: policy, allowlists, sample blocks, exceptions, and a quarterly review record.
• Formalize recurring reviews for approved sources and exceptions.
• Expand coverage to additional environments (dev/test/prod; subsidiaries; remote endpoints).
• Use Daydream-style control mapping: owner, procedure, cadence, and evidence artifacts so CM-7(8) stays operational between audits. ¹

Frequently Asked Questions

Does CM-7(8) mean we must ban all closed-source commercial software?

No. The requirement targets binaries from sources with limited/no warranty or without source code provision. Many commercial products have support terms and controlled distribution; document your rationale and enforce approved sourcing. ¹

How do we handle open-source tools installed by developers?

Treat developer tooling as an executable intake path. Approve specific sources (mirrored repos, pinned packages), enforce via managed workstations and allowlisting, and route nonstandard tools through exceptions with compensating controls. ¹

Are container images “binary or machine-executable code” for CM-7(8)?

Yes in practice, because container layers contain executables and run-time instructions. Control which registries and base images are allowed, require provenance signals, and document the approved image sources. ¹

What counts as “source code provided” if a supplier won’t share their repo?

Define acceptable forms: source escrow, supplier-provided source packages, or other contractual mechanisms that provide access under defined conditions. If none apply, treat it as an exception with compensating controls and explicit risk acceptance. ¹

We have legacy hardware with firmware blobs and no source. Are we automatically noncompliant?

Not automatically, but you need a controlled exception path. Document why source is unavailable, limit exposure (segmentation, monitoring, least privilege), and show active ownership and review of the exception. ¹

What evidence is fastest to produce for an audit?

Provide the executable intake standard, the approved sources list, a sample of allowlisting enforcement output, and at least one completed exception record with compensating controls. This set demonstrates design and operation, not just intent. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5