What Regulation SCI Expects for Open Source Vulnerability Management

Regulation SCI expects an SCI entity to keep written policies and procedures that include regular reviews and testing of its SCI systems to identify vulnerabilities, to hold indirect SCI systems to the same security standards, and to run an SCI review of its compliance at least once a year. It does not name open source, SBOMs or patch deadlines. In practice, that means a component inventory for every in-scope system, a review cadence you can show, remediation and exception records kept for five years, and oversight of the vendors whose software runs inside those systems.

This post is for technology and risk leaders at SCI entities, and for vendors selling into them. It covers the rule text, the withdrawn 2023 amendments, what "current SCI industry standards" means, and a method you can run with any tools. Safeguard comes in near the end.

Key takeaways

• The rule is about policies, testing and review, not about tools. Rule 1001(a)(2)(iv) asks for regular reviews and testing to identify vulnerabilities. Rule 1003(b) asks for an annual SCI review by objective personnel. Both reach open source components.
• Indirect SCI systems count for security. A build server that could threaten an SCI system if breached is held to the same security standards.
• The 2023 proposed amendments are not law. The SEC withdrew them on 17 June 2025 and said it does not intend to finalize them. They still show staff thinking on inventories, third parties and patching.
• Records last five years. Rule 1005(b) requires SCI entities that are not SROs to keep compliance records for at least five years, the first two readily accessible. SROs follow Rule 17a-1. Plan your remediation and exception records for that horizon.
• Safeguard capabilities covered, with labels: SBOM generation and analysis (GA); software composition analysis and vulnerability management with EPSS and CISA KEV (GA); reachability analysis and prioritisation (GA); policies and gates with exceptions and approvals (GA); autonomous remediation (GA, ships switched off with every category set to Manual); Portal, including audit trails and export (GA); TPRM, the Third-Party Risk Manager (GA); the CLI and local runner (GA); Zero AI mode, bring your own model and on-prem or air-gapped deployment (GA); Gold Open Source (GA); fork and patch (GA).
• What stays with you: the legal reading of the rule, the SCI review itself, capacity and resiliency, business continuity, and every notification and Form SCI filing.

Who Regulation SCI covers, and which systems are in scope

Regulation SCI sits at 17 CFR 242.1000 to 242.1007. The Commission adopted it in November 2014 in Release No. 34-73639, and the text has been in the Code of Federal Regulations since December 2014.

SCI entities

Rule 1000 defines an SCI entity as an SCI self-regulatory organization, an SCI alternative trading system, a plan processor, an exempt clearing agency subject to ARP, or an SCI competing consolidator. The SRO part of that definition covers national securities exchanges, registered securities associations (in practice, FINRA), registered clearing agencies and the Municipal Securities Rulemaking Board, with narrow carve-outs for notice-registered exchanges and limited purpose associations.

A software vendor is not an SCI entity, but if its product runs in an SCI system "operated by or on behalf of" one, the customer's obligations reach its code.

Three kinds of system

The definitions in Rule 1000 create three tiers that matter for vulnerability work:

• SCI systems are the computer, network, electronic and automated systems that directly support trading, clearance and settlement, order routing, market data, market regulation or market surveillance, whether the entity runs them or someone runs them on its behalf.
• Critical SCI systems are the subset supporting functions such as clearance and settlement, primary market openings and closings, trading halts and IPOs, or functionality with few or no alternatives.
• Indirect SCI systems are any systems of the entity, or run on its behalf, that "if breached, would be reasonably likely to pose a security threat to SCI systems" (Rule 1000).

Open source programs underestimate that last one. A CI server, an artifact repository or a workstation with deploy rights can be an indirect SCI system, which puts its own plugins and images inside Rule 1001(a)'s security standards.

Where open source sits

Messaging, serialization, logging, TLS, web frameworks for operator consoles, database drivers and container base images in trading and clearing software are usually open source, often several layers down the dependency tree. A known vulnerability in any of them is a vulnerability in the SCI system that ships it.

What do Rules 1001(a) and 1003(b) require on vulnerability reviews, testing and the SCI review?

Rule 1001(a): capacity, integrity, resiliency, availability and security

Rule 1001(a)(1) requires each SCI entity to establish, maintain and enforce written policies and procedures reasonably designed to ensure that its SCI systems, and its indirect SCI systems for purposes of security standards, have adequate capacity, integrity, resiliency, availability and security.

Rule 1001(a)(2) then lists seven minimum elements. Four of them touch vulnerability management directly:

• (a)(2)(iii) a program to keep systems development and testing methodology current, which covers dependency selection and update practice.
• (a)(2)(iv) regular reviews and testing, as applicable, of those systems, including backup systems, to identify vulnerabilities pertaining to internal and external threats, physical hazards, and natural or manmade disasters. This is the core vulnerability requirement.
• (a)(2)(vi) standards for how the systems are designed, developed, tested, maintained and operated so market data flows correctly.
• (a)(2)(vii) monitoring to identify potential SCI events, which include systems intrusions.

The other three (capacity planning, stress tests, business continuity) concern capacity and resiliency.

Rule 1001(a)(3) requires periodic review of the policies' effectiveness and prompt action on deficiencies, so the program has to measure itself.

Rule 1001(a)(4) is the safe harbor. Policies are deemed reasonably designed if they are consistent with "current SCI industry standards", which the rule defines as information technology practices widely available to IT professionals in the financial sector and issued by a US government body, an association of them, or a widely recognized organization. Following those standards is not the only way to comply.

Rule 1001(b): systems compliance and change control

Rule 1001(b) is about SCI systems operating in compliance with the Exchange Act and the entity's own rules. Two of its minimum elements matter for patching: (b)(2)(i) testing of all SCI systems and any changes to them prior to implementation, and (b)(2)(ii) a system of internal controls over changes. A dependency upgrade is a change, so urgent patching needs a documented fast lane, not an informal bypass.

Rule 1003(a): reporting material changes

Rule 1003(a)(1) requires a quarterly report to the Commission, within 30 calendar days after each quarter ends, describing completed, ongoing and planned material changes to SCI systems and to the security of indirect SCI systems. The entity sets its own written criteria for what counts as material. Routine dependency updates rarely qualify; a framework replacement or a sourcing change might, and your criteria should say so.

Rule 1003(b): the annual SCI review

Rule 1003(b)(1) requires an SCI review of the entity's compliance with Regulation SCI at least once each calendar year. Penetration test reviews of the network, firewalls and production systems must happen at least once every three years, and assessments of SCI systems directly supporting market regulation or surveillance follow a risk-based frequency, at least once every three years.

The definition of SCI review in Rule 1000 sets the bar for the evidence. It must follow established procedures and standards, be performed by "objective personnel having appropriate experience", and contain a risk assessment plus an assessment of internal control design and effectiveness covering logical and physical security controls, development processes and IT governance, consistent with industry standards.

The report goes to senior management within 30 calendar days after the review is completed, and then to the Commission and the board, with any management response, within 60 calendar days after that (Rule 1003(b)(2) and (3)).

For open source, a reviewer will ask how you know what is in each system, how you learn of new vulnerabilities, how fast you fix them, and who approved the ones you did not.

Rules 1002, 1005 and 1007: events, records and service bureaus

Rule 1002 covers SCI events, including systems intrusions, defined as any unauthorized entry into SCI systems or indirect SCI systems. When responsible SCI personnel have a reasonable basis to conclude an SCI event has occurred, the entity must begin corrective action, notify the Commission immediately and follow up in writing within 24 hours.

Rule 1005 covers records. SCI SROs keep records under Rule 17a-1. Other SCI entities must keep at least one copy of all documents relating to compliance with Regulation SCI, including records of changes to SCI and indirect SCI systems, for at least five years, the first two in a readily accessible place, and furnish copies promptly on request.

Rule 1007 says that if a service bureau or other recordkeeping service keeps those records, the entity must file a written undertaking that the Commission can examine them, and the entity stays responsible. Whether a platform holding your scan history counts as one is a question for counsel.

What the rule text means for open source, in one table

What did the 2023 proposed amendments add, and what is their status?

In March 2023 the Commission proposed amendments to Regulation SCI in Release No. 34-97143, published in the Federal Register on 14 April 2023 (88 FR 23146). The proposal would have widened the definition of SCI entity to more market participants and amended several existing provisions. Three proposed additions to Rule 1001(a)(2) are directly relevant to open source:

• Proposed (a)(2)(viii), a written inventory. Policies would have had to include maintaining a written inventory and classification of all SCI systems, critical SCI systems and indirect SCI systems. The release called identifying in-scope systems a "foundational and essential step".
• Proposed (a)(2)(ix), third-party provider management. Policies would have had to include a program to manage and oversee third-party providers that provide functionality, support or service, directly or indirectly, for SCI systems and, for security standards, indirect SCI systems.
• Proposed (a)(2)(x), unauthorized access. Policies would have had to include a program to prevent unauthorized access to systems and the information in them. In explaining it, the release said procedures generally should provide for an appropriate patch management cycle so that known software vulnerabilities are identified and patches are deployed and validated in a timely manner.

The proposal also would have added an assessment of third-party provider management risks and controls to the SCI review.

Status: withdrawn

On 17 June 2025 the Commission published a notice withdrawing a group of proposed rules issued between March 2022 and November 2023, including the Regulation SCI amendments at 88 FR 23146. The notice says the Commission does not intend to issue final rules on those proposals and that any future action would start with a new proposal. The same notice withdrew the separate 2023 cybersecurity risk management proposal for broker-dealers, clearing agencies, exchanges and others.

We found no new Regulation SCI proposal in the Federal Register through October 2026, and the eCFR text current to 22 October 2026 has none of the proposed paragraphs. Its inventory, third-party and patch cycle ideas remain good practice, but you cannot cite them as rules.

What does "current SCI industry standards" mean in practice?

What the adopting release says

The 2014 adopting release explains that the list of publications the Commission had proposed as standards was recharacterized as staff guidance that would evolve over time. It says that an entity's choice not to follow some or all of the listed publications does not by itself make its policies unreasonable, that an entity may combine or customize standards, and that it would be appropriate for more rigorous controls to apply to critical SCI systems than to other SCI systems. The release refers to NIST SP 800-53 as an example of a publication treated as a standard rather than a framework.

The staff guidance itself is published separately on sec.gov. We could not retrieve a readable copy on 25 October 2026, so check sec.gov for the current list before you cite it in policy.

Publications that cover open source vulnerability work

Whatever the staff list contains on the day you check, the following US government publications are widely available to financial sector IT professionals and are commonly mapped to Regulation SCI programs:

• NIST SP 800-53 Rev. 5 (September 2020, updated December 2020). The control catalog. For component vulnerabilities the usual anchors are RA-5 (vulnerability monitoring and scanning), SI-2 (flaw remediation), CM-8 (system component inventory) and the SR family for supply chain risk management. Our post on SI-2 versus RA-5 explains how the scanning and fixing controls divide the work.
• NIST SP 800-40 Rev. 4 (April 2022), the enterprise patch management guide. It frames patching as preventive maintenance and a cost of doing business, which is a useful framing for a board report under Rule 1003(b)(3).
• NIST Cybersecurity Framework 2.0. Its Govern function includes supply chain risk management, and its Identify function covers asset management and risk assessment, including identifying vulnerabilities in assets.
• CISA's Known Exploited Vulnerabilities catalog. Binding on federal civilian agencies, not on SCI entities, but the clearest public signal of which CVEs are being exploited. KEV entries now point to BOD 26-04 for federal timelines; our post on BOD 26-04's four factors covers that change.
• FIRST's Exploit Prediction Scoring System (EPSS), which estimates the probability that a published CVE will be exploited in the next 30 days.

In practice: pick a baseline, map your open source procedures to its inventory, scanning and remediation controls, and document any customization.

How should open source components in SCI systems and indirect SCI systems be inventoried?

Regulation SCI never says "SBOM". But you cannot run regular reviews to identify vulnerabilities in components you have not listed. The inventory has two layers.

Layer one: the system inventory

List every SCI, critical SCI and indirect SCI system with its classification and owner, then the artifacts that make up each one: services, binaries, images, appliances and hosted services. Note which you build, which a vendor ships, and which a provider runs.

Layer two: the component inventory

For each artifact you build, generate a software bill of materials at build time in a standard format (SPDX or CycloneDX). For each artifact a vendor ships, ask the vendor for one. Store it against the release, not just the repository, because the review question is "what was running on that date", not "what is on the main branch today".

A component inventory that holds up has these fields:

Indirect SCI systems need their own inventory

Build servers, artifact repositories and admin consoles are rarely scanned as products. If compromising one could alter what reaches an SCI system, its plugins and base images belong in the inventory.

Keep it current through change control

Generate SBOMs in the release pipeline so every tested change refreshes the inventory, and keep superseded ones: they are records of changes under Rule 1005.

How do you turn "regular reviews and testing" into a cadence you can defend?

"Regular" is undefined. The defensible answer is a layered cadence with triggers, written into policy and measured.

1. On every build. Scan the artifact's components and evaluate them against a policy before the release candidate moves on. This doubles as change testing under Rule 1001(b)(2)(i).
2. Daily, without a build. Re-match every deployed SBOM against current vulnerability data. New CVEs appear against old code every day, and a system that has not shipped in months is the one most likely to be carrying an unreviewed finding.
3. On a KEV addition. Treat a new KEV entry that matches any deployed component as an immediate review trigger, with a named owner and a decision recorded the same day.
4. Quarterly. Review backlog age, time to remediate by severity, and open exceptions per system. Feed anything material into the Rule 1003(a) quarterly report process and into the Rule 1001(a)(3) effectiveness review.
5. Annually. Hand the year's evidence to the SCI review team, including the metrics and any policy changes made in response.

Prioritise with more than CVSS

CVSS describes the flaw, not your exposure. Add KEV listing, EPSS, whether your code calls the vulnerable function, and the system's tier.

Set your own remediation targets

Regulation SCI sets no patch deadline. Write internal targets per tier into policy, tighter for KEV-listed findings in critical SCI systems. BOD 26-04 timelines do not bind you but are a fair reference.

What remediation records and exception approvals hold up in an SCI review?

The SCI review assesses control design (the policy) and effectiveness (the records). Four kinds of record matter.

Detection records

Component and version, affected system and artifact, vulnerability ID, first detection date, and priority with the reason. A reviewer should be able to pick any KEV entry from the year and see when you knew whether it affected you.

Remediation records

The change ticket or pull request, test evidence, Rule 1001(b) change approval, deployment date and a closing rescan.

Exception records

Not every finding gets fixed on time. An exception that holds up has:

• the finding and the system it covers, and nothing broader;
• a business and technical justification, including why the vulnerable code is not reachable or not exposed where that is the argument;
• compensating controls, named specifically;
• an approver with authority, independent of the person requesting;
• an expiry date, after which the exception lapses and the finding is open again;
• a record of re-review at expiry.

Exceptions without expiry dates turn into permanent risk acceptance that nobody re-examines. A reviewer will find them.

Program metrics

For the Rule 1001(a)(3) review: open findings by tier and age, time to remediate, exceptions and lapses, and SBOM coverage, kept as quarterly snapshots.

Keep all of it for the Rule 1005 period, somewhere the people being reviewed cannot quietly change it.

How do you oversee vendors whose software runs inside SCI systems?

SCI systems include systems "operated by or on behalf of" the entity. Vendor software inside your SCI systems is your SCI system for the purposes of the rule, and the vendor's open source dependencies come with it.

Tier vendors by the systems they touch

Tie each vendor to systems in your inventory. Software in a critical SCI system puts its vendor in your top tier, whatever the contract value.

Ask for evidence, not attestations

For high-tier vendors, require in contract:

• an SBOM per release, in SPDX or CycloneDX, delivered with the release;
• a vulnerability notification window for findings that affect your deployed version;
• a remediation window, tighter for KEV-listed findings;
• VEX or equivalent statements when a listed component is present but not exploitable;
• cooperation with your SCI review and with Commission examination of related records.

See contract clauses banks expect from software vendors and chasing SBOM requests across many suppliers.

Monitor between releases

Re-match each vendor SBOM daily, as you do your own, so a KEV entry against a vendor component prompts your question before their notice.

If you are the vendor

Assume your customer's reviewer will see your SBOMs, notification history and exception practice. The OTC Link Regulation SCI case shows how the Commission has treated vulnerability policies in an enforcement setting.

A worked example, clearly illustrative

This is an illustrative scenario, not a real entity or event. CISA adds a deserialization CVE in a common Java library to the KEV catalog. The daily re-match flags it three levels down in a market data service (an SCI system) and in an operator console (an indirect SCI system). The owner confirms the service calls the vulnerable class, raises an emergency change through the documented fast lane, and deploys the fixed minor release two days later after regression tests; a rescan closes the finding. The console's vendor has no update yet, so the owner files an exception for that component only, names network isolation as the compensating control, gets approval from the technology risk lead and sets a 30 day expiry, then notifies the vendor under contract. Escalation finds no unauthorized entry, so no Rule 1002 notification is made, and that decision is recorded. At the SCI review, the reviewer samples this KEV entry and finds every step dated.

How Safeguard does this job

Safeguard covers the component layer of an SCI program: inventory, matching, prioritisation, gates, remediation, exceptions, audit trail and vendor SBOMs. Not the rest of Regulation SCI.

Step by step

1. Run scans where your code lives, with the local runner (GA). The runner is part of the Safeguard CLI (GA). Install it with the one-line installer shown in the runner docs:

   # macOS and Linux
   curl -fsSL https://cli.safeguard.sh/install | bash
   

   Then run safeguard, type /login, and approve the session in your browser. The runner polls the platform for jobs over outbound HTTPS only, runs each scan locally, and uploads only the resulting SBOM and findings. The docs state that source code stays on the machine. For a build server, the headless form is:

   safeguard runner start --workspace ./path/to/repo
   safeguard runner status
   

   If even outbound connections to a SaaS tenant are ruled out, Safeguard also offers on-prem and air-gapped deployment (GA), including its models running inside your environment.

2. Generate an SBOM for every artifact (GA). Scan the repository, the container image or an existing SBOM file from the CLI with safeguard scan --dir ., safeguard scan --image <name> or safeguard scan --sbom <file>. Results are written as JSON under ./output. SBOM generation and analysis supports SPDX and CycloneDX, and the software composition analysis (GA) covers the full transitive tree across the major package ecosystems and container layers. Run it in the release pipeline so each release candidate gets its own SBOM.

3. Review findings in the Vulnerabilities tab (GA). In the Enterprise Software Supply Chain Manager, the Vulnerabilities tab groups findings as Critical, High, Medium, Low and Exploitable, where Exploitable means known active exploitation. The vulnerabilities docs say Safeguard re-scans all projects daily and re-evaluates them when new CVEs are published, drawing on NVD, GitHub Security Advisories, OSV, CISA KEV and vendor bulletins. Each finding shows CVSS, EPSS, exploitation status, affected component, fixed version and reachability.

4. Rank with reachability (GA). Reachability analysis and prioritisation classifies each finding as reachable, conditionally reachable, unreachable or unknown, and combines that with EPSS, KEV, runtime context and business context into a 0 to 100 priority score. Unknown is treated conservatively as potentially reachable. The reachability docs list reachability for JVM languages, Python, JavaScript and TypeScript, Go, Rust, C and C++, .NET, static reachability for Ruby and PHP, and both static and dynamic reachability for Swift and Objective-C. That page carries a banner that its /v1 REST endpoints are not yet available, so use the Vulnerabilities tab views rather than the API it describes.

5. Encode your policy as gates (GA). Policies evaluate SBOMs and produce findings; gates enforce them at checkpoints. Create a policy under Settings, then Policies, then Create Policy, using the visual builder or YAML, with conditions such as severity, CVSS or EPSS thresholds. Each policy's action is Block, Warn or Notify. In CI, the policies and gates docs show:

   safeguard ci scan --wait --fail-on-gate <gate>
   

   which fails the job when the gate fails. Use stricter gates for critical SCI systems.

6. Route exceptions through approval (GA). For a policy finding, Request Exception asks for the policy and finding, a business justification and an expiration date, then notifies approvers. The docs list the workflow as request, notification, review, decision, and an audit trail recorded. In the Vulnerabilities tab, Accept Risk similarly takes an expiration date and justification and goes for approval, and Mark False Positive takes a justification and can require approval by policy.

7. Fix with pull requests, under your change control (GA, ships off). Autonomous remediation, with Griffin fix pull requests for one repository or in bulk, ships switched off with every category set to Manual. In the Vulnerabilities tab, AI Remediate generates remediation plans for you to review before pull requests are created, and View Fix shows upgrade options with breaking change warnings. A pull request is a proposed change; it still goes through your Rule 1001(b) testing and approvals. If your model risk policy rules out AI in this path, Zero AI mode (GA) runs the platform deterministically with no LLM in the loop, and bring your own model (GA) lets you use a model already on your approved list.

8. Keep the audit trail and export it (GA). The Portal (GA, here meaning the SBOM publish and share product) keeps audit logs of SBOM activity, access and sharing, and administrative changes including policy modifications. Each entry records timestamp, actor, action, resource, source IP and result. Under Settings, then Audit Logs, filter by date, actor or action and export as CSV, JSON or a PDF report, or send logs to your SIEM from Settings, then Integrations, then SIEM. The audit trails docs give default retention of two years for access logs and seven years for administrative and security event logs, configurable for enterprise customers. Two years is shorter than Rule 1005's five, so set retention or export on a schedule. The page carries the /v1 banner; use the web export.

9. Oversee vendor software with TPRM (GA). In the Third-Party Risk Manager, add vendors to the directory, assign a risk tier, request SBOMs from high tier vendors, review and validate what they submit, then enable continuous monitoring. SBOM requests are tracked from Sent through Viewed, In Progress and Submitted to Validated or Rejected, with automated follow-ups. Vendor risk scores run from 0 to 100, where higher is better, and draw on EPSS and KEV. Monitoring alerts on new critical vulnerabilities, KEV additions and SBOM expiry. The TPRM docs suggest quarterly SBOM updates for the critical tier, which you can map to vendors inside critical SCI systems.

Requirement, Safeguard, and what you still own

What Safeguard does not do

• It does not interpret Regulation SCI. Safeguard gives no legal view on which of your systems are SCI systems, what counts as a material change, whether an event is an SCI event, or whether your policies are reasonably designed. Your counsel and compliance team decide those.
• It is not your SCI reviewer. Rule 1003(b) requires a review by objective personnel. Safeguard produces evidence for that review. It does not perform it, sign it or report it to anyone.
• It covers software components, not capacity or resiliency. Capacity planning, stress testing, business continuity and disaster recovery under Rule 1001(a)(2)(i), (ii) and (v), and member testing under Rule 1004, are outside what it does.
• It does not file anything with the Commission. Form SCI submissions, immediate and 24 hour SCI event notifications, quarterly material change reports and SCI review reports stay with the entity.
• It does not replace penetration testing. Rule 1003(b) penetration test reviews of networks, firewalls and production systems are separate.
• Reachability is input, not the whole case. Static reachability for Ruby and PHP, and Swift and Objective-C reachability, are covered too. Treat any reachability result as input, not as the sole basis for an exception.
• The documented /v1 REST endpoints for reachability queries and audit logs are not available yet. Plan exports through the web interface and the CLI.
• About Safeguard as your vendor: Safeguard is designed for FedRAMP High, and its SOC 2 Type II audit is in progress. If Safeguard becomes part of an indirect SCI system in your environment, put it through the same vendor oversight as anyone else.

Common mistakes

• Scoping only production. Indirect SCI systems are in scope for security standards. Build servers, artifact stores and admin consoles carry open source too.
• Inventorying repositories instead of releases. The review question is what ran on a date. An SBOM tied to a deployed version answers it; a repository scan of today's main branch does not.
• Treating the 2023 proposal as law. It was withdrawn in June 2025. Citing it as a requirement in policy or in a vendor contract invites the wrong conversation.
• Exceptions with no expiry. An open-ended risk acceptance is a control that has stopped working. Every exception needs an end date and a re-review.
• Upgrading outside change control. A dependency bump that skips Rule 1001(b) testing and approval fixes one problem and creates another. Build a documented fast lane instead.
• Ignoring vendor components. Software run on your behalf is in scope. Without vendor SBOMs, a KEV entry against a vendor's bundled library is invisible until the vendor tells you.
• Letting tool retention set record retention. If a platform keeps logs for two years and Rule 1005 needs five, the gap is yours. Export on a schedule.

FAQ

Does Regulation SCI require an SBOM?

No. The rule text never mentions software bills of materials. It requires policies with regular reviews and testing to identify vulnerabilities and an annual SCI review. An SBOM per release is a practical way to meet those requirements for open source components and to keep the change records Rule 1005 asks for.

How often does Regulation SCI require vulnerability scanning?

The rule says "regular reviews and testing" without a frequency. The SCI review is at least annual and penetration test reviews at least every three years. Most programs combine scanning on every build with daily re-matching of deployed components and immediate review when a KEV entry matches.

Are the 2023 Regulation SCI amendments in effect?

No. The Commission proposed them in March 2023 and withdrew them on 17 June 2025, saying it does not intend to finalize them. Any future change would start with a new proposal. The eCFR text current to 22 October 2026 contains none of the proposed paragraphs.

What counts as an indirect SCI system?

Rule 1000 defines it as any system of, or operated by or on behalf of, an SCI entity that, if breached, would be reasonably likely to pose a security threat to SCI systems. Build infrastructure, artifact repositories and administrative tools often qualify. Indirect SCI systems are subject to the security standards of Rule 1001(a).

Which NIST controls map to open source vulnerability management under Regulation SCI?

The common anchors in NIST SP 800-53 Rev. 5 are RA-5 for vulnerability monitoring and scanning, SI-2 for flaw remediation, CM-8 for component inventory, and the SR family for supply chain risk. NIST SP 800-40 Rev. 4 covers enterprise patch management. Check the SEC staff guidance on current SCI industry standards for the publications staff list.

How long must vulnerability records be kept under Regulation SCI?

SCI entities that are not SROs must keep compliance records, including records of changes to SCI and indirect SCI systems, for at least five years, the first two in a readily accessible place (Rule 1005(b)). SCI SROs follow Rule 17a-1.

Does a vulnerable open source component trigger an SCI event notification?

Not by itself. A known vulnerability is not an SCI event. A systems intrusion, meaning unauthorized entry into SCI or indirect SCI systems, is. If exploitation is suspected, the entity's escalation procedures under Rule 1001(c) decide whether responsible SCI personnel have a reasonable basis to conclude an event occurred.

Do Regulation SCI obligations apply to software vendors?

Not directly. They apply to SCI entities, but SCI systems include systems operated on the entity's behalf, so vendors should expect contract terms on SBOMs, notification and remediation, and requests to support the entity's SCI review.

Most of the Regulation SCI findings above end with a fix that someone has to ship, often under change control and sometimes before upstream has moved. The section below describes how Safeguard helps close that gap for open source dependencies, with the limits stated plainly.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows the local runner: you set it up on your own machine, approve it with its device code, then scan from the terminal. For an SCI entity, the same pattern runs on a build server or an analyst workstation inside the controlled network, so the scan happens locally and only the SBOM and findings reach the platform.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session: install, run safeguard to open the interactive terminal, and ask it to "fix the lodash CVE in this repo". It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. In an SCI setting, that local, approved change is the starting point for your normal change ticket and test cycle, not a substitute for it.

Click through it at your own pace, or open it full screen.

To try it on your own systems, download the CLI and apps from safeguard.sh/download and read the setup guides at docs.safeguard.sh/docs. Related posts in this series: keep a contract promise of no known exploited vulnerabilities and prove every production release passed a security gate.

Quick check

Sources

• 17 CFR 242.1000, Definitions (eCFR)
• 17 CFR 242.1001, Obligations related to policies and procedures of SCI entities (eCFR)
• 17 CFR 242.1002, Obligations related to SCI events (eCFR)
• 17 CFR 242.1003, Obligations related to systems changes; SCI review (eCFR)
• 17 CFR 242.1004, Business continuity and disaster recovery testing (eCFR)
• 17 CFR 242.1005, Recordkeeping requirements (eCFR)
• 17 CFR 242.1006, Electronic filing and submission (eCFR)
• 17 CFR 242.1007, Requirements for service bureaus (eCFR)
• SEC, Regulation Systems Compliance and Integrity, adopting release No. 34-73639 (2014)
• SEC, Regulation Systems Compliance and Integrity, proposed amendments, release No. 34-97143 (2023)
• SEC, Withdrawal of Proposed Regulatory Actions, 17 June 2025 (govinfo)
• Federal Register, Withdrawal of Proposed Regulatory Actions, document 2025-11110
• NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• NIST Cybersecurity Framework 2.0
• CISA Known Exploited Vulnerabilities Catalog
• FIRST, Exploit Prediction Scoring System (EPSS)
• Safeguard docs: Vulnerabilities
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: Policies and Gates
• Safeguard docs: Portal Audit Trails
• Safeguard docs: Third Party Risk Manager
• Safeguard docs: Local Runner

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.