Construction and Engineering Supply Chain Security: Rules, 90-Day Plan

Construction and engineering firms secure their software supply chain by knowing which open source and commercial components sit inside the systems they run on every project (BIM and design tools, the common data environment, field apps, estimating and job cost systems, and the connected equipment and OT on site), fixing flaws in that software on a schedule that fits live jobs, and asking every software supplier for the same records. In the United States the hard requirements come through contracts and disclosure rules rather than one construction regulation: CMMC and DFARS for defense work, FAR 52.204-21 for federal contracts, the SEC's 2023 cybersecurity disclosure rules for listed firms, and the owner's own security clauses. A 90-day plan built around an inventory, a fix process and supplier evidence gets most firms to records they can show an owner, a prime, an insurer or an assessor.

Everything up to "How Safeguard does this" works with whatever tools you already have. Nothing here is legal or contract advice; your contracts, your counsel and your assessor decide what applies to you.

Key takeaways

• Construction runs on project-scoped software shared by the contractor, subcontractors, designers and owner, so every supplier's software is part of your exposure.
• There is no single US construction cybersecurity regulation. Requirements arrive through federal contract clauses (FAR 52.204-21, DFARS 252.204-7012 and the CMMC program), SEC disclosure rules for public companies, and owner contracts that increasingly cite NIST, ISO 19650-5 or CISA guidance.
• The CMMC program rule (32 CFR part 170) took effect on 16 December 2024 and the DFARS rule that puts CMMC into contracts took effect on 10 November 2025. Contractors on defense construction and facilities work can now see CMMC requirements in solicitations.
• Real incidents in the last three years hit the software this industry uses: an exploited flaw in municipal asset and permitting software (February 2025), ransomware at a listed engineering services firm (November 2024), a backdoor in a compression library (March 2024) and a self-spreading compromise of npm packages (September 2025).
• Ownership is split across the CIO or CISO, the VDC or BIM lead, site IT, contracts and GRC, and procurement, each needing evidence at a different moment: bid, mobilisation, handover, renewal or incident.
• Safeguard capabilities covered in this post, all generally available (GA): SBOM generation and analysis, software composition analysis with deep transitive dependency scanning, vulnerability management with EPSS and CISA KEV, Third-Party Risk Manager (TPRM), CSAF and VEX upload, policies and gates, the compliance and GRC suite (CMMC and IEC 62443 mappings), the Safeguard CLI and local runner, on-prem and air-gapped deployment, Zero AI mode and autonomous remediation (which ships switched off).

The situation

The trigger usually starts outside IT: a defense facilities solicitation with a CMMC level in it, an owner's master services agreement asking for an SBOM for every application that touches its building data, a data center client's security schedule in the bid documents, an insurer asking how you patch job site software, or a Friday advisory for a library inside the field app every superintendent uses.

Who asks: the owner, the prime contractor, a contracting officer, an insurer or your audit committee. By when: the bid due date, the notice to proceed or the renewal date, none of which move because your software inventory lives in one person's spreadsheet.

A bad week: a critical flaw is published in a widely used library and the CIO asks which systems are affected. Corporate IT can answer for the laptops. Nobody can answer for the BIM plugins your VDC team wrote, the field app's sync service, the drone processing workstation in the site trailer, the telematics gateway on rented equipment or the building automation software being commissioned. The owner wants an answer before the weekly OAC meeting.

What software construction and engineering firms run

Construction is unusual because so much of its software is project scoped. A job may last two years, bring together dozens of companies and then hand everything to an owner who will operate the building for fifty. Here is where software sits, and where the open source inside it hides.

Corporate and project controls systems

• ERP and job cost accounting, holding job cost, certified payroll, retention and vendor payments, hosted or on premises with custom reports.
• Estimating, takeoff and scheduling tools, often with plugins and import filters for many file formats.
• Project management and document control for RFIs, submittals, change orders and drawings, usually multi-tenant SaaS with mobile clients and public APIs.
• Integration glue: scripts, small web services and integration flows between ERP, project management, scheduling and payroll. These are most often written in house, by one person, with dependencies nobody tracks.

Design, BIM and engineering software

• BIM authoring and coordination tools, plus the add-ins, scripts and visual programming graphs your VDC team writes on top of them. Revit add-ins are often .NET code with NuGet dependencies; Dynamo and Grasshopper graphs pull in Python packages and community node libraries.
• The common data environment (CDE), the shared space where models and documents are exchanged under ISO 19650 workflows. It may be a vendor platform, a file server or both.
• Open formats and parsers. IFC files, point clouds, CAD formats and PDFs pass through many parsers. File parsing libraries are a classic place for memory safety flaws, and a malformed file from another party lands on the same workstation as everything else.
• Engineering analysis, GIS and reality capture: structural and civil design software, laser scanning and drone image processing, often on high specification workstations that miss the corporate patch cycle.

Field and site software

• Field apps on phones and tablets, used by superintendents, foremen and subcontractors, often on personal devices. They carry offline data stores, sync services and embedded SDKs.
• Site networks and the trailer. Temporary networks, routers, cameras, access control, time and attendance kiosks, and printers, set up per job and torn down at the end.
• Connected equipment and machine control. Telematics units, GNSS machine guidance, total stations and their controllers, tower crane monitoring, and sensors for concrete maturity, vibration and environmental monitoring. Firmware and companion apps come from the equipment maker or a rental company.

The building you hand over, and software you sell

Building automation, fire and life safety, access control and metering systems are installed by trade contractors and commissioned before handover. Their software becomes the owner's OT, but its versions are fixed during your project. Firms that also ship client portals, digital twin products or design automation tools are software suppliers themselves, with customers asking them for SBOMs.

Why the supply chain is wider than it looks

The bottom three rows are where most firms have the least visibility and the least contractual pull. The top two are where you can act fastest.

The regulations and frameworks that apply

US construction has no sector cybersecurity regulator. Obligations come from who your client is, whether you are listed and what your contracts say. Status below is as of 25 October 2026.

CMMC and DFARS for defense construction and facilities work

The Department of Defense's Cybersecurity Maturity Model Certification program is set out in 32 CFR part 170, published as a final rule in the Federal Register on 15 October 2024 and effective 16 December 2024. A separate DFARS rule (DFARS Case 2019-D041), published on 10 September 2025 and effective 10 November 2025, incorporates the contractual requirements for CMMC into the DFARS, which is how CMMC levels reach DoD solicitations and contracts.

Why a contractor cares: military construction, facilities sustainment and engineering services contracts involve Federal Contract Information and often Controlled Unclassified Information, which on a construction job can include facility drawings, security system designs and site plans. Section 170.14 of the rule says which requirements each level uses: FAR 52.204-21 for Level 1, NIST SP 800-171 Revision 2 for Level 2, and selected requirements from NIST SP 800-172 (February 2021) for Level 3.

DFARS 252.204-7012 still sits underneath. Among other things it requires contractors to "rapidly report" cyber incidents, which the clause defines as within 72 hours of discovery. Flow down matters in construction because covered information goes to subcontractors and design consultants too. If your mechanical subcontractor receives the controls drawings for a secure facility, the requirements follow the drawings; check your prime contract's flow down clauses for the exact terms.

The software supply chain link is direct. NIST SP 800-171 Revision 3, published in May 2024, has a supply chain risk management family with three requirements: 03.17.01 Supply Chain Risk Management Plan, 03.17.02 Acquisition Strategies, Tools, and Methods, and 03.17.03 Supply Chain Requirements and Processes. CMMC Level 2 assessments are built on Revision 2, as the rule text shows, so treat Revision 3 as the direction of travel and confirm with your assessor which revision applies to you.

FAR 52.204-21 for federal contracts

FAR 52.204-21, Basic Safeguarding of Covered Contractor Information Systems, applies broadly to federal contracts where the contractor's systems process, store or transmit Federal Contract Information. It lists fifteen basic safeguarding requirements, including limiting system access to authorised users, identifying and authenticating users and devices, and identifying, reporting and correcting information system flaws in a timely manner. That last requirement is a software patching requirement in plain words, and it applies to the systems that hold your federal project data.

SEC cybersecurity disclosure rules for listed firms

The SEC adopted its cybersecurity risk management, strategy, governance and incident disclosure rules on 26 July 2023. Listed companies disclose a material cybersecurity incident on Form 8-K Item 1.05, generally within four business days after determining it is material, and describe their processes for assessing and managing cybersecurity risk, including risks from third parties, in the annual report on Form 10-K (Regulation S-K Item 106). For a listed contractor, software suppliers and project SaaS platforms belong in that description.

NIST frameworks owners and primes ask for

Owners and primes often write "align with the NIST Cybersecurity Framework" into security schedules. NIST CSF 2.0, released in February 2024, added the Govern function, which includes cybersecurity supply chain risk management as its own category (GV.SC). NIST SP 800-161 Rev. 1 is the deeper reference for cybersecurity supply chain risk management practices and is where many federal owners point when they ask about supplier controls.

ISO 19650-5 for security-minded information management

ISO 19650-5:2020 is the security-minded part of the ISO 19650 series on information management using BIM. BSI, which published it in the UK in July 2020, describes it as specifying the principles and requirements for a security-minded approach to information management, aimed at helping organisations involved in the design, construction, operation and decommissioning of assets reduce the risks from sensitive information that could affect the safety, security and resilience of built environment services. It addresses building an appropriate and proportionate security mindset and culture across every organisation with access to that information, including monitoring and auditing compliance. It is not a software patching standard, but it is often the document an owner of a sensitive facility points to when asking how you protect the CDE, the models and the software that touches them.

CISA guidance that owners quote

Three CISA documents show up in owner and prime requirements:

• The 2026 Minimum Elements for a Software Bill of Materials (29 July 2026), which replaces the NTIA 2021 minimum elements as the reference for what an SBOM should contain. If an owner asks for "an SBOM that meets the minimum elements", this is now the document.
• Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products (13 January 2025), which lists security elements to look for when buying OT products: configuration management, logging, open standards, ownership, protection of data, secure by default, secure communications, secure controls, strong authentication, threat modeling, vulnerability management, and upgrade and patch tooling. Its supply chain questions include whether the manufacturer has drawn up a software bill of materials. Contractors who install building automation and site OT can use the same list with their own suppliers.
• Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators (13 August 2025), which describes building and maintaining an OT asset inventory. That is close to the record an owner wants at handover.

CISA also counts commercial facilities as a critical infrastructure sector, and many of the buildings contractors deliver serve sectors such as water, energy, transportation and government facilities. Owners in those sectors bring their own regulators' expectations to your door.

IEC 62443 for the OT you install and operate

ISA/IEC 62443 is the series of standards for the security of industrial automation and control systems. Part 3-3 covers system security requirements and security levels, with requirements such as control system component inventory (SR 7.8) and software and information integrity (SR 3.4). Part 4-1 covers secure product development lifecycle requirements for suppliers, including practices for externally provided components and the identification of third-party components. Controls specifications for buildings and infrastructure can reference 62443, and contractors who integrate those systems inherit the questions.

International context

Firms that work in Europe will meet the EU Cyber Resilience Act for products with digital elements. The European Commission says it entered into force on 10 December 2024, with reporting obligations applying from 11 September 2026 and the main obligations from 11 December 2027. The EU Machinery Regulation (EU) 2023/1230, adopted on 14 June 2023, adds provisions on cyber safety for compliance-relevant software, data and safety control systems; machinery placed on the EU market before 20 January 2027 must still comply with the Machinery Directive. Both reach construction mainly through the equipment and products you buy.

How the pieces fit

Real public incidents from the last three years

These incidents come from official or primary sources. We describe what the sources say and draw no conclusions about what any organisation should have done.

An exploited flaw in municipal asset and permitting software (February 2025)

On 6 February 2025 CISA published an industrial control systems advisory for Trimble Cityworks. It described a deserialization of untrusted data vulnerability (CVE-2025-0994) in Cityworks versions before 15.8.9, and Cityworks with office companion before 23.10, that could allow an authenticated user to perform remote code execution against a customer's Microsoft Internet Information Services web server. The advisory listed the affected critical infrastructure sectors as water and wastewater, energy, transportation, government services and facilities, and communications, and said CISA had received reports of active exploitation. CISA added CVE-2025-0994 to its Known Exploited Vulnerabilities catalog on 7 February 2025. Engineering firms that implement, host or integrate public works and asset management systems for municipal and utility clients support exactly this kind of software.

Ransomware at a listed engineering services firm (November 2024)

ENGlobal Corporation, a listed engineering services company, filed a Form 8-K under Item 1.05 (Material Cybersecurity Incidents) reporting that on 25 November 2024 it became aware of a cybersecurity incident. The filing said a preliminary investigation showed a threat actor had accessed its IT system and encrypted some of its data files, and that the company took steps to contain, assess and remediate the incident, including an internal investigation, engaging external cybersecurity specialists and restricting access to its IT system. The filing is an example of how the SEC rules turn an incident at an engineering firm into a public, dated record within days.

A backdoor in a compression library (March 2024)

On 29 March 2024 CISA reported a supply chain compromise affecting XZ Utils, a data compression library present in many Linux distributions, after malicious code was found in versions 5.6.0 and 5.6.1 (CVE-2024-3094). CISA recommended downgrading to an uncompromised version. The library can sit in the servers, appliances and containers behind field app back ends, integration services and site gateways, so "do we run an affected version anywhere" is an inventory question.

A self-spreading compromise of npm packages (September 2025)

On 23 September 2025 CISA reported a widespread supply chain compromise of the npm registry, in which a self-replicating worm compromised over 500 packages. CISA said the actor deployed malware that scanned environments for sensitive credentials and then targeted GitHub. Its recommendations included pinning npm dependency versions to known safe releases produced before 16 September 2025, rotating all developer credentials and requiring phishing resistant multifactor authentication on developer accounts. Any firm with web front ends, client portals, field app tooling or integration services built in JavaScript has npm dependencies, whether or not anyone calls them software developers.

The personas who own the problem

Software risk in construction is owned by several people who rarely sit in the same meeting. Each needs a different record at a different moment.

What each role is really asking

The CIO or CISO wants to answer a client or regulator in hours, and measures coverage: share of systems with a current inventory, and the age of the oldest open critical finding. The VDC or BIM lead wants to update add-ins, graphs and scripts without breaking a model the week before a coordination milestone, so needs a package list and a test step before templates change. The field and site IT lead needs a per-site register with firmware versions and update owners, plus a demobilisation plan. The contracts or GRC lead needs to know what the solicitation or owner schedule actually requires and which evidence satisfies it. The procurement owner needs a short standard request and a way to track who answered across a long, project-driven supplier list. The commissioning lead needs the versions and known issues of building systems documented before turnover.

Step by step: a 30/60/90-day plan

This plan works with or without a platform. It assumes a firm with a small central IT or security team, a VDC group that writes some code, and more projects than people.

Days 1 to 30: scope and inventory

1. Name owners. One executive sponsor (CIO or COO), one owner per layer in the supply chain table above, and one contracts or GRC contact for client requirements.
2. List your requirement sources. Pull the security clauses from active contracts and current bids: FAR and DFARS clauses, CMMC levels in solicitations, owner security schedules, insurer questionnaires. Record each requirement, its source and its due date.
3. Inventory corporate and project systems. ERP, estimating, scheduling, project management, CDE, document control and payroll. For each, record vendor, hosting model, version, integrations and data held.
4. Inventory the code you write. Find every repository and shared folder with BIM add-ins, scripts, integration services, portals and data pipelines. You will be surprised by the count. Generate an SBOM for each with an open source SBOM generator in CycloneDX or SPDX format.
5. Pick two pilot sites and list devices, apps and connected equipment with firmware versions, using CISA's asset inventory guidance.
6. Set severity rules. Decide how fast you fix a finding based on severity, whether it is in CISA's Known Exploited Vulnerabilities catalog and its EPSS score. Write it down in one page.

Days 31 to 60: fix, gate and ask suppliers

1. Fix the critical and known exploited findings in code you own. Start with internet-facing services and anything that touches the CDE or ERP.
2. Add a release check. In the build or release process for your own code, fail or warn on known exploited and critical vulnerabilities and on disallowed licenses, with documented exceptions that expire.
3. Pin and review dependencies. Commit lockfiles, pin versions in BIM scripting environments and review new packages before they reach project templates.
4. Send a standard SBOM and vulnerability request to your top suppliers. Start with the ten software and SaaS suppliers that hold the most project data, and the equipment and rental suppliers on your pilot sites. Ask for an SBOM aligned to CISA's 2026 minimum elements, their advisory channel, their VEX or advisory format, and their patch commitments.
5. Set up advisory intake: one channel where vendor advisories, CISA alerts and KEV additions are triaged against your inventory.
6. Write the handover record template for building systems: system, vendor, software and firmware versions, known open vulnerabilities, compensating controls, owner contact.

Days 61 to 90: prove it and keep it running

1. Run a tabletop on a supplier incident. Use one of the incidents above. Time how long it takes to answer "are we affected" for corporate, project and site software.
2. Map evidence to your top requirement. For defense work, map your inventory, flaw remediation and supplier records to the NIST SP 800-171 requirements your assessment uses. For owner schedules, map them clause by clause.
3. Extend to all active sites by turning the pilot register into a mobilisation checklist.
4. Report. Give leadership four numbers: share of systems with a current SBOM or vendor inventory, open critical and known exploited findings with age, suppliers who have answered the request, and exceptions past their expiry.
5. Schedule the cadence. Monthly supplier follow-up, weekly triage, quarterly review of exceptions and requirements.

Template: supplier SBOM request (plain text you can adapt)

Please provide a software bill of materials for the version of your product we use, in CycloneDX or SPDX format, aligned with CISA's 2026 Minimum Elements for a Software Bill of Materials. Please also tell us where you publish security advisories, whether you publish VEX or CSAF documents, how quickly you fix critical and known exploited vulnerabilities, and who we should contact about a security issue. We will use this information only to manage risk on our projects and will treat it as confidential.

Decision table: what to do with a finding

Illustrative scenario: one advisory, 48 hours

This scenario is illustrative, with invented round numbers. On a Thursday a critical flaw is published in a popular .NET library. The firm has 40 internal repositories, 12 of them BIM add-ins, each with an SBOM, so a search finds the library in 3 add-ins and 1 integration service that afternoon. The VDC lead tests the upgrade on a copy of the project template on Friday and releases it to 6 active projects on Monday. Two SaaS suppliers are asked for statements: one replies with a VEX saying not affected, one gives a fix date. The CIO answers the owner on Friday morning.

How Safeguard does this

Safeguard is a software supply chain security platform. The steps below follow the plan above and use only flows described in Safeguard's offering documentation and docs.safeguard.sh. Every capability named here is generally available (GA). Commands are shown as the docs show them; we did not run them for this post.

1. Generate SBOMs for the software you build. SBOM generation and analysis (GA) and software composition analysis with deep transitive dependency scanning (GA) cover your BIM add-ins, scripts, integration services and portals. The Safeguard CLI (GA) signs in with safeguard login, or safeguard login --no-browser on a machine without a browser, and scans one target at a time:

   safeguard login --no-browser
   safeguard scan --dir .
   safeguard scan --image myregistry.example.com/field-sync:3.2
   

   The image name is illustrative. Results are written under ./output by default. The docs say safeguard scan does not fail on findings: it exits 0 when the scan ran. Release decisions are made by policy gates in the platform.

2. Check vendor SBOMs before you trust them. The CLI validates a supplier SBOM and scans it locally:

   safeguard validate sbom.json
   safeguard scan --sbom sbom.json
   

3. Request SBOMs from suppliers and track the answers. Third-Party Risk Manager (TPRM, GA) turns the supplier request in the plan into a tracked workflow. Requests can go to one vendor or many at once, from a default template or custom templates under Settings, Request Templates, so yours can name CISA's 2026 minimum elements. Requests move through statuses such as Viewed, In Progress and Rejected, with reminders 7 days before the deadline, at the deadline, and an escalation 7 days after. Each submitted SBOM is checked for format and completeness and scanned automatically; if it falls short, you specify the corrections and the vendor receives an update request.

4. Score and monitor suppliers. TPRM scores each vendor from 0 to 100 (0 to 25 critical, 76 to 100 low risk) from vulnerability, compliance, component and operational factors. Monitoring alerts you when an exploited CVE in a vendor's SBOM is added to CISA KEV, when a score drops below your threshold or when an SBOM is older than your threshold; alerts are configured under Settings, Monitoring. When you decide to live with a vendor risk, click Accept Risk and record it.

5. Ingest vendor advisories and VEX. CSAF and VEX upload (GA) takes CSAF 2.0 advisories and VEX documents in CycloneDX, OpenVEX and CSAF VEX formats. Go to Integrations, filter by Upload and use the upload card. This is the "vendor says not affected" row of the decision table, recorded rather than remembered. Vulnerability management with EPSS and CISA KEV (GA) puts those signals next to every finding.

6. Map evidence to CMMC and IEC 62443. The compliance and GRC suite (GA) includes CMMC 2.0 and IEC 62443 mappings, on unless you switch them off in Compliance, Manage. For CMMC, each product scan checks the SBOM for a software inventory baseline, identifiable components for vulnerability scanning, supply chain risk management, audit trail timestamps and unique component identifiers; further catalog controls are evidenced with tests, uploads, policies or an attestation, and CMMC policy templates are included. For IEC 62443, scans check component inventory (SR 7.8), integrity hashes (SR 3.4) and supplier and component identification (4-1 SM-9 and SM-10). These checks show whether your SBOMs carry what a requirement presupposes; they do not assess your whole CMMC or 62443 program, and they do not replace a certified assessor.

7. Gate releases of your own code. Policies, gates and guardrails (GA) enforce your release rules. Go to Settings, Policies, define conditions with the visual builder or YAML (for example no critical CVEs, no abandoned packages, approved licenses only) or start from a pre-built template. Each policy's action decides what a failure does: Block (the gate fails), Warn (the gate passes with a warning) or Notify (the gate passes and a notification is sent). Exceptions carry a business justification, go to approvers who grant or deny them, and are tracked. In CI, with policy outcomes on for your workspace, the docs show:

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

   Replace the placeholder with your gate's name; the job fails when the gate fails.

8. Scan where you cannot grant a cloud service access. The local runner (GA) is part of the CLI. Type /login, approve the session in the browser, and the machine polls the platform for scan jobs. All traffic is outbound HTTPS that the runner opens. It scans locally and uploads only the SBOM and findings, never your source code. That suits VDC teams whose add-in code lives on a file share or a private server. On networks that forbid held connections, the docs show safeguard runner start --workspace ./path/to/repo with --poll-wait 0 to poll at a fixed interval.

9. Run inside a sensitive perimeter. For firms holding CUI or working on sensitive projects, on-prem and air-gapped deployment (GA) runs the platform inside your perimeter. Signed snapshot bundles arrive through a receiver in the DMZ that verifies signatures, by one-way diode, signed removable media or a scheduled DMZ sync, on a cadence from hourly to quarterly, and no component inside the perimeter calls outbound. Zero AI mode (GA) runs the platform with no language model in the loop. Safeguard's own posture: designed for FedRAMP High, with the SOC 2 Type II audit in progress.

10. Fix dependencies in code you own. Autonomous remediation (GA) uses Griffin to open tested, policy gated fix pull requests, single or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own. It applies to your own repositories, never to a vendor's product or a machine's firmware.

Requirement, what Safeguard does, what you still own

What Safeguard does not do

• It does not patch vendor products, SaaS platforms or equipment firmware. When the flaw is in a construction ERP, a SaaS project platform, a telematics unit or a building automation controller, the fix comes from that vendor, maker or rental company. Safeguard helps you request, record and track their evidence.
• It does not inventory your site devices for you. Cameras, kiosks, sensors and machine control units need a register maintained by site IT. Safeguard works from SBOMs, scans and supplier records.
• It does not certify you. CMMC certification comes from a C3PAO or a government assessment, and owner audits are decided by the owner. Framework mappings show where your evidence stands, not a pass.
• It does not decide risk for you. Accepting a vendor risk, granting a gate exception or handing over a building system with a known issue is a decision for a named person in your firm, with the owner where the contract says so.
• It does not judge an incomplete supplier SBOM as complete. Validation checks format and required fields; whether a supplier's SBOM truly reflects what is deployed on your project is still a judgment.
• It does not handle incident notification. The 72 hour DFARS report, an SEC Form 8-K and any owner notification are your firm's obligations.

Common mistakes

• Treating project software as someone else's problem. SaaS platforms and subcontractor tools hold your data; the supplier request belongs in onboarding, not after an incident.
• Forgetting the code the VDC team writes. Add-ins and scripts are software with dependencies. They need SBOMs like anything else.
• Asking suppliers for "your security policy". Ask for specific records: an SBOM, an advisory channel, a fix commitment and a contact.
• Missing flow down. CUI and owner security requirements follow drawings and data to subcontractors and consultants.

FAQ

Is there a cybersecurity regulation specifically for construction companies in the US?

No single one. Requirements come from federal contract clauses, CMMC for defense work, the SEC rules for listed companies, owner contracts and the regulators of the sectors you build for.

Do construction contractors need CMMC?

DoD contracts that involve Federal Contract Information or CUI can carry CMMC requirements under the DFARS rule effective 10 November 2025, including construction and facilities contracts. The level depends on the information involved: Level 1 uses FAR 52.204-21 and Level 2 uses NIST SP 800-171 Revision 2.

Does CMMC apply to subcontractors and design consultants?

Subcontractors and consultants that handle FCI or CUI on a defense job can be asked to meet CMMC requirements too. Check the solicitation and your prime's flow down clauses for what applies to you.

What is ISO 19650-5?

It is the part of the ISO 19650 series that sets principles and requirements for a security-minded approach to information management, so that sensitive information about built assets is protected across everyone who handles it.

Should a general contractor ask software vendors for SBOMs?

Yes, for platforms that hold project data or run on project networks. Ask for an SBOM aligned with CISA's 2026 minimum elements, an advisory channel and fix commitments.

Are BIM add-ins and Dynamo scripts part of the software supply chain?

Yes. They are code with third-party dependencies, they run on workstations with access to models and the CDE, and they need an inventory and an update process.

What should we hand the owner about building system software at turnover?

The system, vendor, software and firmware versions, known open vulnerabilities, compensating controls and a vendor contact, in the format the owner's specification asks for.

Does the SEC disclosure rule apply to private contractors?

No. It applies to SEC registrants. Private firms meet similar expectations through owner contracts, lenders and insurers.

Related reading

• Construction and AEC security: protecting shared BIM project data
• Construction sites: when software supply chain risk becomes a physical safety issue
• Construction equipment software and vulnerable dependencies
• What to ask suppliers about machine firmware bills of materials
• Software supply chain security for manufacturing OT

The Gold block below covers fixes for open source you build and ship, which in construction means your add-ins, integrations and portals. Vendor products and site equipment still depend on their makers, as the limits above say.

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 sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. It is the pattern for VDC and integration code that lives on a file share or private server you will not connect to a cloud service.

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

The second demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal with safeguard, and asks it to "fix the lodash CVE in this repo". The assistant 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. The same flow applies to the JavaScript dependencies in a client portal, a field app back end or an integration service your team maintains.

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

The third demo is a real Android session with the Safeguard mobile app. It sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. For a digital construction lead who spends the day on site rather than at a desk, it shows how a fix on the office workstation can still wait for a human decision.

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

Quick check

Sources

• Federal Register: Cybersecurity Maturity Model Certification (CMMC) Program, 32 CFR part 170 (15 October 2024)
• eCFR: 32 CFR 170.14, CMMC Model
• Federal Register: DFARS, Assessing Contractor Implementation of Cybersecurity Requirements (10 September 2025)
• Acquisition.gov: DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting
• Acquisition.gov: FAR 52.204-21, Basic Safeguarding of Covered Contractor Information Systems
• NIST: SP 800-171 Rev. 3
• NIST: SP 800-171 Rev. 3 (PDF)
• NIST: SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• NIST: Cybersecurity Framework
• NIST: The NIST Cybersecurity Framework (CSF) 2.0 (PDF)
• SEC: SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure by Public Companies
• BSI: New international standard for BIM security-minded approach to information management (ISO 19650-5)
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Secure by Demand, Priority Considerations for OT Owners and Operators
• CISA: Secure by Demand OT guide (PDF)
• CISA: Foundations for OT Cybersecurity, Asset Inventory Guidance for Owners and Operators
• CISA: Commercial Facilities Sector
• ISA: ISA/IEC 62443 Series of Standards
• European Commission: Cyber Resilience Act
• European Commission: Machinery
• CISA: ICSA-25-037-04, Trimble Cityworks (Update A)
• CISA: CISA Adds One Known Exploited Vulnerability to Catalog (7 February 2025)
• SEC: ENGlobal Corporation Form 8-K, Item 1.05
• CISA: Reported Supply Chain Compromise Affecting XZ Utils (CVE-2024-3094)
• CISA: Widespread Supply Chain Compromise Impacting npm Ecosystem
• Safeguard docs: Safeguard CLI usage
• Safeguard docs: Local Runner
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Risk Assessment
• Safeguard docs: TPRM Monitoring
• Safeguard docs: CSAF/VEX Upload
• Safeguard docs: Policies and Gates
• Safeguard docs: CMMC 2.0
• Safeguard docs: IEC 62443
• Safeguard docs: Air-Gapped Deployment

To try the flows above, download Safeguard at safeguard.sh/download and read the documentation at docs.safeguard.sh/docs.

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