SI-14(1): Refresh from Trusted Sources

SI-14(1) requires you to refresh system components and services using software and data only from pre-approved trusted sources, then prove it with repeatable evidence. To operationalize it, define what “refresh” means in your environment, maintain an allowlist of trusted sources, enforce retrieval through controlled channels, and retain verification records for every refresh event. ¹

Key takeaways:

• Build and govern a “trusted sources” allowlist that covers OS images, containers, firmware, patches, and reference data.
• Force refresh workflows to pull only from those sources, with integrity checks and change-control traceability.
• Treat evidence as a first-class deliverable: you need logs, approvals, and provenance for each refresh. ¹

The si-14(1): refresh from trusted sources requirement is a supply chain integrity control disguised as an operations requirement. Refreshes happen during patching, re-imaging, autoscaling, disaster recovery, golden image updates, container base image updates, and third-party managed service maintenance. Each refresh is an opportunity to accidentally introduce tampered software, poisoned dependencies, unvetted configuration, or untrusted “reference” data.

SI-14(1) is narrow in wording but broad in operational footprint. It does not ask you to “be secure” in the abstract. It asks you to obtain the software and data used for refresh from trusted sources that you define and can defend. Your fastest path to assessment-ready implementation is to (1) define refresh events and in-scope assets, (2) establish trusted-source criteria and an allowlist, (3) route all refresh acquisition through controlled repositories and procurement paths, and (4) produce consistent evidence that refreshes followed the rule.

If you support federal information systems or operate as a contractor handling federal data, SI-14(1) is also a third-party risk issue: many refresh inputs come from external publishers, cloud marketplaces, managed service providers, and open-source registries. ²

Regulatory text

Requirement (verbatim): “Obtain software and data employed during system component and service refreshes from the following trusted sources: {{ insert: param, si-14.01_odp }}.” ¹

Operator translation: For any refresh activity (rebuild, redeploy, restore, patch, re-image, roll forward), you must only pull the software and data used to perform that refresh from sources you have designated as trusted. The “trusted sources” parameter is intentionally organization-defined; your job is to define it, enforce it, and prove it. ¹

Plain-English interpretation (what SI-14(1) actually demands)

SI-14(1) is satisfied when all refresh inputs come from sources with known provenance and controlled access, and your refresh pipelines make it difficult (ideally impossible) for engineers or automated tooling to fetch from random internet locations.

In practice, auditors look for two things:

1. A clear definition of trusted sources (publishers, repositories, internal artifact stores, approved third parties).
2. Operational enforcement (technical controls and workflow constraints) plus evidence that refreshes followed the rule. ¹

Who it applies to

Entities

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractors handling federal data where NIST SP 800-53 requirements flow down through contractual/security requirements. ²

Operational contexts (where you will trip over this)

• Endpoint re-imaging and “break/fix” rebuilds
• Server/VM golden image refreshes
• Container rebuilds and base image updates
• Firmware and device OS updates (network gear, IoT, OT where applicable)
• Cloud managed services refresh/maintenance coordinated through a third party
• Restores from backup and disaster recovery rebuilds
• Patch management that downloads content from upstream sources (OS repos, language package registries)

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

1) Define “refresh” for your environment

Document which events count as a refresh and therefore must comply:

• Re-image, rebuild, redeploy, restore, patch, firmware update, immutable replacement, autoscaling node creation. Tie this definition to your asset inventory categories (endpoints, servers, containers, network devices, managed services).

Output: “Refresh scope statement” owned by IT Ops/SecOps with CCO/GRC approval.

2) Define “trusted sources” and create an allowlist

Create a governed list of approved sources for software and data used in refreshes. Include:

• OS repositories and update channels
• Internal artifact repositories (e.g., signed golden images, internal container registry, internal package mirror)
• Approved cloud marketplace publishers (if allowed)
• Firmware sources (manufacturer portals) and validation method
• Approved reference datasets used during refresh (configuration baselines, hardening scripts, parameter files)

Set acceptance criteria per source type:

• Ownership (publisher identity), access control, integrity verification approach, and change notification expectations
• Contractual coverage for third parties that provide refresh inputs (for managed services, marketplaces, patch feeds)

Practical tip: Don’t keep this as a spreadsheet that nobody updates. Put it under change control with an accountable owner and a review trigger when new platforms are onboarded.

Output: Trusted Sources Standard + Allowlist.

3) Force refresh workflows to pull only from those sources

You need enforcement points. Pick the ones that match your architecture:

• Network egress controls: block direct access to unapproved package registries and download sites from build subnets and admin networks.
• Repository controls: require builds and refresh jobs to pull from internal mirrors/registries.
• Configuration management: pin repositories, enforce signed packages where supported, and block “curl | bash” patterns in automation.
• CI/CD guardrails: policy-as-code checks for base images and dependencies; restrict runners to controlled networks.
• Golden image pipeline: only allow image creation from approved base images; store images in controlled galleries.

Output: Technical enforcement mappings (control-to-system mapping) and implemented guardrails.

4) Add integrity and provenance verification to refresh inputs

SI-14(1) says “obtain from trusted sources,” but operationally you should be prepared to show you also verify what you obtained:

• Verify publisher identity where possible (certs, signed packages, signed images).
• Hash verification for downloaded artifacts when signatures are unavailable.
• Maintain provenance metadata for images/artifacts (source, version, retrieval time, pipeline/job ID).

Output: Documented verification procedure and system settings/screenshots showing enforcement.

5) Put refreshes under change control (even if automated)

Auditors often ask: “Show me that a refresh event followed policy.” Your answer should link:

• Request/approval (or pre-approved standard change)
• The job/pipeline execution
• The artifact/source used
• The target assets updated

For high-frequency automated refreshes (autoscaling, immutable rollouts), use:

• Pre-approved change models + pipeline controls + logging as your evidence chain.

Output: Change templates and traceability model.

6) Make evidence collection automatic and recurring

Manual evidence collection fails under pressure. Configure recurring exports or dashboards:

• Artifact registry logs showing pulls from approved repos
• Build logs showing base image digests and source registry
• Patch tool logs showing update source configuration
• Firewall/proxy logs showing blocks of unapproved sources (helpful to prove enforcement)
• Exceptions register for emergency refreshes, with approvals and compensating controls

Output: Evidence pack checklist per platform, refreshed on a cadence aligned to assessment needs.

Required evidence and artifacts to retain

Use this as an assessment-ready checklist:

Evidence	What it proves	Owner
Trusted Sources Standard + allowlist (version-controlled)	Defined trusted sources	GRC + SecOps
Refresh scope statement	Which activities are governed	IT Ops
System configuration evidence (repo settings, registry settings, policy-as-code rules)	Enforcement in tooling	Platform teams
Artifact provenance records (digests, signatures, SBOM/provenance if available)	What you pulled and from where	DevOps/SecOps
Change records (or standard change documentation) tied to refresh events	Traceability	ITSM owner
Logs: build, deployment, patch, proxy/firewall	Operational compliance	SecOps
Exceptions register with approvals	Controlled deviations	GRC

Daydream can help by turning this into a requirement-owned evidence map: named control owner, step-by-step procedure, and a recurring evidence checklist that doesn’t rely on institutional memory.

Common exam/audit questions and hangups

• “Define a refresh. Does this include container rebuilds and autoscaling?” Expect this question. Have a written definition and scope boundaries.
• “Show me your trusted sources list. Who approves changes to it?” Auditors want governance, not a static list.
• “Demonstrate that engineers cannot download packages from the public internet during refresh.” Be ready with network controls, build runner design, and logs.
• “How do you validate authenticity of what you download?” Show signatures/hashes and where verification is enforced.
• “How do you handle third-party managed refreshes?” Show contractual language, shared responsibility notes, and how you validate inputs or constrain sources. ¹

Frequent implementation mistakes (and how to avoid them)

1. Allowlist exists, but refresh tooling bypasses it. Fix: route refresh acquisition through internal mirrors/registries and block direct outbound where feasible.
2. Trusted source = “the internet plus TLS.” Fix: define trust as a governed relationship or controlled repository, plus integrity checks.
3. No coverage for “data” used in refresh. Fix: include configuration baselines, scripts, and reference datasets in scope, not only executables.
4. Exceptions are informal (Slack approvals). Fix: implement an exceptions register with time bounds, approver, rationale, and compensating controls.
5. Evidence is ad hoc. Fix: define platform-specific evidence outputs and automate collection into an audit folder or GRC system.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this requirement, so you should treat SI-14(1) primarily as an assessment and risk control. The risk is straightforward: untrusted refresh inputs can introduce malicious or vulnerable components into otherwise stable systems, and refresh events happen under operational urgency when controls get bypassed. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and governance)

• Name a control owner (typically SecOps or Platform Security) and a GRC partner accountable for assessment readiness.
• Write and approve: refresh definition, in-scope platforms, and the initial trusted sources criteria.
• Create the trusted sources allowlist for your top platforms (endpoints, server images, container images, patch repos).
• Start an exceptions register and require it for any out-of-band refresh downloads.

Days 31–60 (enforce through architecture)

• Implement internal mirrors/registries where gaps exist, or restrict outbound access from refresh/build networks to approved endpoints.
• Add CI/CD checks for base images and dependencies to enforce approved registries and pinned digests.
• Update ITSM change models to cover automated refreshes with pre-approval plus logging requirements.
• Define the evidence pack per platform and test evidence retrieval end-to-end.

Days 61–90 (operationalize and make it auditable)

• Run a tabletop: pick a recent refresh event and produce a complete evidence chain in one sitting.
• Close edge cases: emergency patching, third-party managed services, developer workstations doing “local” rebuilds.
• Add ongoing monitoring: alerts on downloads from unapproved sources in refresh networks, plus periodic allowlist review workflow.
• In Daydream, map SI-14(1) to the control owner, the step-by-step procedure, and recurring evidence artifacts so assessment prep is repeatable. ¹

Frequently Asked Questions

What counts as a “trusted source” for SI-14(1)?

A trusted source is one you explicitly approve and govern, with defined criteria (publisher identity, access control, integrity verification, and change management). The key is consistency: the same definition must drive both tooling enforcement and audit evidence. ¹

Does SI-14(1) apply to containers and Kubernetes nodes?

Yes if your refresh activities include rebuilding images, updating base images, or recreating nodes. Treat container registries, base images, and Helm charts (or equivalent) as refresh inputs and restrict them to approved sources.

How do we handle third-party managed services where the provider performs refreshes?

Require the third party to disclose their trusted sources and refresh supply chain controls through contract language and due diligence, then document your shared responsibility stance. Keep evidence of the third party’s commitments and your review/approval process. ²

Are internal artifact repositories required to meet SI-14(1)?

No single architecture is mandated, but internal repositories are the cleanest way to enforce “trusted sources” at scale. If you rely on direct upstream access, you need strong controls to restrict destinations and prove retrieval only occurred from approved sources.

What evidence is most persuasive in an audit?

Auditors respond well to an evidence chain that ties a refresh event to a specific approved source and verification outcome: change record (or standard change), build/deploy logs showing artifact digests, and registry/proxy logs showing the pull came from an allowlisted source.

How do we treat “data” used during refresh (not software)?

Include configuration baselines, hardening scripts, parameter files, and reference datasets in your trusted sources program. Store them in controlled repositories and require approvals and integrity checks just like software.

Footnotes

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

2. NIST SP 800-53 Rev. 5