Software Supply Chain Security for Media and Gaming: A 90-Day Plan

Software supply chain security for a game studio, streamer, broadcaster or entertainment company comes down to three jobs: know every engine version, SDK and open source package inside the software you ship (games, launchers, apps, players and the services behind them), know which vendor or partner maintains every tool in your content pipeline, and run both on a patch clock that someone owns and can prove to a platform holder, a content owner, a regulator or a board. In this industry the two halves meet inside shipped builds that sit on millions of devices for years, so a flaw in an engine runtime or a mobile SDK is a fleet problem, not a single server problem. A focused team can stand up the inventory, the release gates and the vendor evidence in about 90 days.

This guide covers the software the industry runs, the US rules and industry programs that apply, three recent public incidents, the people who own each part, and a 30, 60 and 90 day plan that works with any tools. Safeguard appears only near the end. Nothing here is legal, regulatory or audit advice; your counsel, your platform agreements and your content owners decide what applies to you.

Key takeaways

• The program has to cover code you build (clients, servers, launchers, apps, pipeline tools) and code you license (engines, middleware, platform, ad and analytics SDKs, production tools), including builds already in players' hands.
• The amended COPPA Rule took effect on 23 June 2025, with compliance due 22 April 2026. Section 312.8 now requires a written information security program and written assurances from third parties that handle children's data.
• Public companies in the sector report material cybersecurity incidents on Form 8-K Item 1.05 and describe their processes for third-party service provider risk under Regulation S-K Item 106.
• Platform holders and content owners act like regulators: Apple requires privacy manifests and signatures for listed third-party SDKs, and studios expect content vendors to follow the MPA Content Security Best Practices through the Trusted Partner Network (TPN).
• The three incidents below came through software the victim did not write: a game engine runtime flaw (October 2025), a fake AI art tool behind a Slack data leak (July 2024) and an npm worm (September 2025).
• Six roles own the problem: CISO, VP of Engineering or technical director, product security, GRC, vendor risk, and build and live operations.
• Safeguard capabilities covered in this post, all GA: SBOM generation and analysis, software composition analysis (SCA), vulnerability management with EPSS and KEV, reachability analysis and prioritization, policies, gates and guardrails, autonomous remediation (ships switched off), SAST, DAST, license compliance, Third-Party Risk Manager (TPRM), the Compliance and GRC suite, Trust Center, Portal audit trails, the CLI and local runner, and on-prem, air-gapped and Zero AI deployment options.

What software media, gaming and entertainment run

The software falls into a handful of families, each with a different owner and a different answer to the question "if this has a critical flaw tomorrow, how do we ship the fix?"

Game clients, engines and middleware

A modern game is an engine, a set of middleware libraries and the studio's own code, compiled into a build for each platform. The engine may be a commercial one licensed per seat or per revenue, an open source engine, or a proprietary in-house engine with years of vendored third-party code. Middleware covers physics, audio, animation, networking, voice chat, video playback, compression, crash reporting and localization. Many of these ship as binaries rather than source.

That matters twice over. The engine runtime is compiled into every build, so a runtime flaw is fixed only by rebuilding and redistributing each affected title, or with a vendor patch tool. And catalog titles keep running on players' machines long after their teams have moved on, often on engine generations nobody recorded.

Anti-cheat, launchers and platform SDKs

Competitive games ship anti-cheat components, some running with high privilege on the player's machine. Launchers handle updates and authentication. Platform SDKs from console makers, PC storefronts and app stores handle payments, matchmaking and entitlements, and console SDKs are usually licensed under nondisclosure terms that limit what can be shared with outside scanners. Each has its own update path, and the studio still answers to players for all of them.

Mods, user-generated content and creator tools

Many games ship editors, scripting runtimes and mod loaders, and some host marketplaces for user-generated content. Mods run code neither the studio nor the platform wrote. The open source plugins that artists and modders install into editors and digital content creation (DCC) tools are a supply chain of their own, on the same workstations that hold unreleased assets.

Live service backends

Online games and streaming services run backends for accounts, matchmaking, inventories, chat, telemetry and payments, usually as containerized services on the same open source stacks as any web company. In-game stores and subscription checkout bring card payments into scope.

Streaming, playback and ad delivery

Streamers and broadcasters run transcoding farms, packagers, content delivery, digital rights management clients, server-side ad insertion and players for web, mobile, smart TV and connected TV devices, many built on open source projects. Web players and sign-up flows pull in large JavaScript dependency trees and third-party analytics and ad scripts.

Content production pipelines

Film, television, animation and visual effects pipelines run on DCC tools, render farm schedulers, asset management and review tools, glued together with scripting (mostly Python) and open source image, color and scene description libraries maintained by industry foundations. Pre-release content flows through dozens of outside vendors, from dubbing houses to visual effects shops.

Corporate and AI tooling

Studios also run ordinary corporate software plus a growing set of AI tools for art, audio, localization and code. AI plugins and model files are new components with weak provenance, as the second incident below shows.

The regulations and frameworks that apply

There is no single federal software supply chain law for media and gaming in the United States. The obligations come from privacy rules, securities disclosure, payment card rules, platform holder requirements and content owner programs. The sections below lead with US rules; EU rules appear only as context for companies that sell there.

The amended COPPA Rule (16 CFR Part 312)

The FTC published amendments to the Children's Online Privacy Protection Rule in the Federal Register on 22 April 2025. The amended rule took effect on 23 June 2025, and the FTC gave regulated entities until 22 April 2026 to comply with most of the changes. It applies to operators of websites and online services, including games and apps, that are directed to children under 13 or that have actual knowledge they collect personal information from children.

Section 312.8 is the part that touches software supply chains. As amended, it requires a written information security program with safeguards appropriate to the sensitivity of the data and the operator's size and complexity. Under 312.8(b)(1) to (b)(5), the operator must designate employees to coordinate it, assess internal and external risks at least annually, design safeguards for those risks, regularly test and monitor them, and evaluate and modify the program at least annually.

Section 312.8(c) adds a vendor duty. Before allowing other operators, service providers or third parties to collect or maintain children's personal information on the operator's behalf, or before releasing it to them, the operator must take reasonable steps to determine that they can protect it, and must obtain written assurances that they will.

For a game or app with a young audience, the third-party SDKs that collect data inside the client (analytics, advertising, crash reporting, voice chat) are exactly the third parties 312.8(c) describes. The rule does not use the words "software bill of materials", but an annual risk assessment that cannot list the SDKs in each shipped build is hard to defend.

SEC cybersecurity disclosure rules

Public studios, publishers, streamers and broadcasters are subject to the SEC's 2023 cybersecurity disclosure rules, published in the Federal Register on 4 August 2023. Form 8-K Item 1.05 requires disclosure of a cybersecurity incident the company determines to be material, generally within four business days of that determination. Regulation S-K Item 106 requires annual disclosure of the company's processes for assessing, identifying and managing material cybersecurity risks, including whether it has processes to oversee and identify risks from cybersecurity threats associated with its use of third-party service providers.

A compromised engine plugin or an exploited SDK can therefore become a disclosure question within days, and the inventory work below is what lets a CISO answer "are we affected?" fast enough to support counsel's materiality decision.

PCI DSS v4.0.1 for in-game stores, subscriptions and ticketing

Any studio, streamer or entertainment company that stores, processes or transmits cardholder data, or whose systems can affect that security, is assessed against PCI DSS. Version 4.0's future-dated requirements became mandatory on 31 March 2025. Requirement 6.3.2, as the Council's Summary of Changes describes it, calls for an inventory of bespoke and custom software to support vulnerability and patch management. Requirements 6.4.3 and 11.6.1 cover scripts on payment pages and detection of unauthorized changes to them. In-game stores, subscription sign-up pages and ticketing checkouts are where these land.

Platform holder requirements

For many studios, the strictest supply chain rules come from the stores that distribute their software.

Apple's third-party SDK requirements say that when you use a third-party SDK, you are responsible for all the code it includes in your app. Apple publishes a list of commonly used SDKs that must include a privacy manifest, and signatures when used as binary dependencies, whenever a new app or an update that adds one of those SDKs is submitted to App Store Connect. Xcode validates that a new version of a signed SDK was signed by the same developer, which Apple describes as improving the integrity of the software supply chain.

Console and PC platform holders set their own certification and security terms, usually under nondisclosure agreements. They are not public; treat their patch terms as hard deadlines.

MPA Content Security Best Practices and the Trusted Partner Network

The Trusted Partner Network (TPN) is the Motion Picture Association's content security program for the companies that handle pre-release film and television content. TPN maintains the MPA Content Security Best Practices, which describe what content owners expect from vendors, and runs a directory of accredited independent assessors. Studios use TPN status as a condition of engaging post-production, localization and distribution vendors.

TPN is not a regulation, but for a vendor it works like one: no acceptable assessment, no work. Download the current best practices from TPN and read them against your own pipeline; this guide does not quote their control numbers.

Federal guidance you can borrow

Two federal documents make useful templates even though they bind only federal agencies and suppliers.

• NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, describes practices for producing secure software, including protecting all forms of code from tampering (PS.1), archiving each release (PS.3) and identifying vulnerabilities on an ongoing basis (RV.1). It is a sensible yardstick for a studio's build process.
• CISA's 2026 Minimum Elements for a Software Bill of Materials, published on 29 July 2026, replace the 2021 NTIA minimum elements. Use them as the format checklist when you ask engine, middleware and SDK vendors for SBOMs.

EU context: the Cyber Resilience Act

For companies that sell software products in the EU, the Cyber Resilience Act (Regulation (EU) 2024/2847) applies to products with digital elements. Its vulnerability and incident reporting obligations apply from 11 September 2026, and its main obligations from 11 December 2027. Whether a given game, app or device is in scope is a question for counsel.

Real public incidents from the last three years

The three incidents below come from official or primary sources. Each one reached its victims through software they did not write. The descriptions stick to what the sources say.

A high-severity flaw in a game engine runtime (October 2025)

On 2 October 2025, Unity published a security advisory for CVE-2025-59489, an untrusted search path weakness (CWE-426) in applications built with the Unity Editor. Unity rated it high severity with a CVSS score of 8.4. Its advisory says the issue was discovered on 4 June 2025 by an external researcher, that applications built with affected versions could be affected on Android (code execution or elevation of privilege) and on Windows, macOS and Linux (elevation of privilege), and that affected editor versions go back to 2017.1. Unity stated it had no evidence of exploitation or impact on users, and that fixes were available to all developers. For platforms not listed, it recommended rebuilding games and applications with updated versions.

The shape of the fix is what makes this an industry case. The flaw sat in the runtime compiled into every shipped build, so each developer had to rebuild affected titles with a patched editor version, then push updates through each store. The version table lists no patched release for the oldest branches. A studio that cannot say which engine version each title was built with cannot start.

A fake AI art tool and a leak of internal Slack data (July 2024)

On 1 May 2025, as reported by CBS News Los Angeles citing the Justice Department, a Santa Clarita man agreed to plead guilty to federal charges for hacking a Disney employee's computer. In his plea agreement he admitted posting a program that claimed to create AI-generated art on several online platforms, including GitHub. Once downloaded, it gave him access to the computer. The employee downloaded it between April and May 2024. He used stored credentials to reach the company's Slack workspace, downloaded 1.1 terabytes of data from thousands of channels, posed as a fictitious hacktivist group, and released the data on 12 July 2024.

The pattern that matters for this industry is the route in. The lure was the kind of AI art tool that artists and technical artists try every week, on machines that also hold credentials for internal systems. No server vulnerability was involved.

A self-replicating worm in the npm registry (September 2025)

On 23 September 2025, CISA published an alert on a widespread supply chain compromise of npm, the JavaScript package registry. CISA said a self-replicating worm, publicly known as Shai-Hulud, had compromised over 500 packages. After gaining access, the malware scanned for credentials, targeted GitHub personal access tokens and cloud API keys, exfiltrated them, and used compromised developer credentials to publish infected versions of other packages.

Streaming web apps, ticketing front ends, web-based launchers and live operations dashboards all depend on npm. CISA recommended reviewing dependencies, checking lockfiles for affected versions including nested ones, searching caches and artifact repositories, pinning to known safe versions, rotating developer credentials and enforcing phishing-resistant multifactor authentication.

What the three have in common

Each arrived as a trusted component installed on purpose, each started with an inventory question (which builds, which workstations, which lockfiles), and each needed a fix path outside the normal server patch cycle: rebuilds, workstation cleanup or credential rotation.

The personas who own the problem

Supply chain security fails when it is nobody's job and stalls when it is one person's job. These roles usually own a piece.

The CISO

Needs: a defensible answer to "are we affected?" within hours of an advisory, a short list of material third-party risks for the board, and evidence for the Item 106 description of how third-party risk is managed.

When: the morning an engine or SDK advisory lands, the quarterly board pack, the annual 10-K cycle, and every incident where counsel is weighing materiality.

The VP of Engineering or studio technical director

Needs: an engine and middleware version map for every live and catalog title, a release process that catches known-vulnerable components before certification, and patch work that does not wreck the content roadmap.

When: engine upgrades, platform certification submissions, seasonal content drops and any advisory that requires a rebuild.

The head of product security

Needs: a prioritized view of vulnerable dependencies across client, server and web code; scanning of first-party code; a policy for anti-cheat, mod loaders and scripting runtimes; and a way to run exceptions without email threads.

When: every release train, after every advisory, and before major launches when attention peaks.

The GRC or content security compliance lead

Needs: a COPPA 312.8 written security program with an annual risk assessment, testing evidence and vendor assurances; TPN assessment readiness; PCI DSS evidence for in-game stores and subscriptions; and SEC disclosure support.

When: the TPN assessment cycle, the annual COPPA program review, the PCI assessment, and the 10-K drafting season.

The procurement or vendor risk owner

Needs: a tiered register of engine, middleware, SDK, post-production, localization and streaming technology vendors, with contract terms that require SBOMs, vulnerability notification and fix timelines, and the written assurances that COPPA 312.8(c) calls for.

When: new vendor onboarding, contract renewals, studio content security requests, and the day a vendor appears in an advisory.

Build, release and live operations engineering

Needs: pipeline checks that are fast, report first and block later, rollback paths for live services, and a way to rebuild and resubmit a title without a fire drill.

When: every build, every server deploy, and every out-of-hours advisory during a live event or launch window.

Step by step: a 30, 60 and 90 day plan that works with any tools

This plan assumes a mid-sized studio or media company with a mix of games or apps, live services and outside vendors. Scale it up or down. Nothing here requires a specific product.

Days 1 to 30: see what you run

1. Name owners. For each software family in the first table, write down one accountable owner and the patch path. Put it in the security program document; it is part of what COPPA 312.8(b)(1) asks for if you serve children.
2. Build the title and service register. List every live title, every catalog title still sold or playable, every app and every live service. For each, record the engine and version, platform targets, the last build date and whether you can still build it.
3. Generate SBOMs for code you build. Run an SBOM generator against each repository and each container image for live services, web players and launchers. Use lockfiles so transitive packages appear.
4. Record what scanners cannot see. Engine runtimes, binary middleware and console SDKs often do not appear in a package manifest. Add them by hand to a CycloneDX or SPDX file per title, with name, supplier and version.
5. Inventory client SDKs. For each mobile and web client, list analytics, ad, crash reporting, voice and payment SDKs, the data each collects and whether the app is child-directed. On iOS, start from the privacy report Xcode builds from SDK privacy manifests.
6. Inventory creative workstation tooling. List the plugins, extensions and scripts that artists and pipeline teams install into DCC tools and editors. Decide which sources are approved.
7. Start a vendor register. Tier engine, middleware and SDK vendors, post-production and localization vendors, streaming technology vendors and outsourcing partners as Critical, High, Medium or Low.

Days 31 to 60: control what changes

1. Set the patch clock. Agree target times by severity and exploitation, for example faster for KEV-listed or high EPSS findings in internet-facing services.
2. Add report-only checks in CI. Run dependency and SBOM checks on every pull request and build for live services, launchers and web clients. Report only for the first few weeks.
3. Agree the block list. Typical starting points: known exploited vulnerabilities, critical findings with a fix available, and licenses your legal team has ruled out for shipped clients.
4. Lock down creative tooling. Install plugins and extensions only from an approved list, and keep pipeline package installs pinned and mirrored through an internal repository where possible.
5. Protect build and publishing credentials. Enforce phishing-resistant MFA for source control, package registries and store publishing accounts, rotate long-lived tokens and remove them from developer machines, in line with CISA's npm guidance.
6. Ask Critical vendors for SBOMs. Request SPDX or CycloneDX aligned with CISA's 2026 minimum elements, a vulnerability notification commitment and a fix timeline. For services that receive children's data, collect the written assurances 312.8(c) calls for.
7. Write the rebuild runbook. For an engine advisory, document how to find affected titles, who decides rebuild versus vendor patch, how to resubmit to each store, and how to tell players.

Days 61 to 90: prove it works

1. Turn on blocking for the agreed list. Keep everything else as warnings and notifications.
2. Run an exception process. Every exception has a justification, an approver, an expiry date and a compensating control.
3. Run a tabletop. Pick an engine runtime advisory or a package registry worm and walk through it with engineering, security, legal, communications and live operations.
4. Rebuild one catalog title. Prove that the oldest title you still sell can be rebuilt with a patched engine. If it cannot, record that as a risk with an owner.
5. Map evidence to obligations. Point each COPPA 312.8 element, PCI requirement and TPN expectation at the SBOMs, logs and records that support it.
6. Report. Give the CISO and board a one-page view: coverage, open exposure by title and service, vendor SBOM status, exceptions and their expiry.

A checklist you can use today

Illustrative scenario: an engine runtime advisory on a launch week

This is an illustrative scenario with round invented numbers. A studio with 12 live and catalog titles learns of a high-severity engine runtime advisory on the Tuesday of a launch week. With a title register, the technical director knows by mid-morning that 5 titles are affected, 3 can be rebuilt on a patched branch within the week, 1 needs a vendor patch tool, and 1 is on a branch with no patched release. Product security confirms the new release is unaffected because its pipeline gate blocks the vulnerable runtime version. The CISO briefs counsel with facts, not guesses. Without the register, that morning goes on hunting for old build machines.

How Safeguard does this

Everything above works without Safeguard. This section shows the same plan in Safeguard, using only flows from docs.safeguard.sh. Every capability named here is generally available (GA). Commands are copied as the docs show them; we did not run them for this post.

1. Inventory the software you build

Safeguard's Enterprise Software Supply Chain Manager (ESSCM, GA) generates SPDX and CycloneDX SBOMs (SBOM generation and analysis, GA) and runs software composition analysis (SCA, GA) across each project's full transitive dependency tree. Per the docs, you connect repositories or container registries under Integrations, or upload files, and Safeguard creates the project and its SBOM. Continuous scanning re-evaluates existing projects when vulnerability data changes, so a newly listed KEV entry is matched against builds you already have, including catalog titles you are not actively developing.

If your source code may not leave your network, which is common for unreleased titles and code under platform nondisclosure terms, the local runner (GA) in the Safeguard CLI (GA) runs scans on your own machine and uploads only the SBOM and findings, never source code. The docs show:

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

# start the interactive terminal, then type /login
safeguard

On a headless build server, the docs show:

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

On-prem and air-gapped deployment (GA) and Zero AI mode (GA), which runs the platform with no large language model in the loop, suit studios with stricter rules.

2. Prioritize by exploitation and reachability

Vulnerability management (GA) enriches findings with EPSS scores and CISA KEV status, and reachability analysis and prioritization (GA) adds whether your application calls the vulnerable code. Together they rank the backlog the head of product security works through. SAST (GA) covers your own server, launcher and web code, DAST (GA) tests web targets you have verified, such as a staging store or sign-up page, and license compliance (GA) flags license obligations in components you ship inside game clients and apps.

3. Turn the patch clock into policies and gates

Policies, gates and guardrails (GA) put the clock in the pipeline. Per the docs, you go to Settings › Policies, click Create Policy, define conditions such as severity, CVSS, EPSS, license, component age and maintenance in the visual builder or YAML, and choose an action.

The docs show this GitHub Actions workflow:

name: Safeguard
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

For the report-only weeks in days 31 to 60, drop --fail-on critical. The API key is created under Settings › Developer with the scans:trigger and scans:read scopes.

4. Run exceptions through a recorded approval

Approval runs through exceptions, not through a gate action. Per the docs, a developer clicks Request Exception, selects the policy and finding, gives a justification and an expiration date, and submits; an approver decides, and the audit trail records it.

For findings you will not fix yet, such as a catalog title on an engine branch with no patched release, the Mitigations tab records the mitigation type (Risk Acceptance, False Positive, Workaround Applied or Not Applicable), the justification, the approver, an optional expiry for risk acceptances, and supporting evidence. That becomes the GRC lead's exception register.

5. Fix faster where a fix exists

Autonomous remediation (GA) opens fix pull requests that move a vulnerable dependency to a fixed version, for one repository or in bulk. It ships switched off, with every category set to Manual, so nothing changes in your repositories until your team turns it on. It works on dependencies declared in your repositories; an engine upgrade still goes through your own engine team.

6. Bring vendors inside the clock with TPRM

Third-Party Risk Manager (TPRM, GA) is where the procurement and vendor risk owner works. Per the docs:

1. Vendors › Add Vendor records the company, contact, products used and risk tier (Critical, High, Medium, Low). CSV bulk import moves a register that started in a spreadsheet. Contract records hold dates, SLA terms, security requirements and SBOM obligations.
2. Request SBOM, or Bulk Request for many vendors at once, sends a request specifying SPDX or CycloneDX format, required fields and a deadline, with reminders as the deadline approaches.
3. An arriving SBOM is validated for format and completeness and scanned for vulnerabilities; Request Revision sends back one that falls short.
4. Monitoring alerts on new critical vulnerabilities and CISA KEV additions that affect a vendor's SBOM, and reassessment can be triggered by contract renewals and security incidents. Reports export as PDF or Excel.

For a studio or streamer, the Critical tier usually holds engine and core middleware vendors, SDKs in child-directed apps, payment and identity providers, and vendors that touch pre-release content.

7. Keep the evidence in one place

The Compliance and GRC suite (GA) holds frameworks, controls, evidence and tests. Per the docs, PCI DSS v4.0 is in the framework library: open it under Compliance › Frameworks, and its Connectors tab shows which connected systems feed its tests. The docs say a passing test is evidence toward a control, not proof that it is met. For COPPA 312.8 and TPN expectations, map the SBOMs, vendor records and exception logs above to your own control list; the docs do not describe a COPPA or TPN framework, so do not assume one exists.

Portal audit trails (GA) log SBOM activity, access and administrative changes. Per the docs, you view them under Settings › Audit Logs and export as CSV, JSON or PDF for the assessment folder.

8. If you are the vendor, answer your customers once

Middleware makers, post-production houses and co-development studios answer studio questionnaires constantly. Trust Center (GA) publishes a page with your compliance status, controls, policies, subprocessors and documents. Per the docs, you manage it under Compliance › Trust Center and publish explicitly; nothing goes live on its own. Portal (GA) handles sharing the SBOMs you publish with customers.

What Safeguard does not do

• It does not rebuild or redistribute your games. When an engine runtime flaw needs a rebuild, your engine and build teams do it and your platform holders approve the update.
• It does not see what is not declared. Engine runtimes, binary middleware and console SDKs that do not appear in a manifest, lockfile or container image will not show up unless you record them yourself or the vendor supplies an SBOM.
• It does not police mods or user-generated content. Reviewing what players upload to your marketplace or load through a mod loader is a separate content and platform policy job.
• It does not monitor payment page scripts in the player's browser. PCI DSS requirements 6.4.3 and 11.6.1 need a mechanism that sees what the browser actually receives. Safeguard's docs describe no browser-side script monitoring.
• It does not decide COPPA, PCI or TPN outcomes. Counsel, your QSA and accredited TPN assessors decide. A passing test in Safeguard is evidence toward a control, as the docs say, not a finding of compliance.
• It does not make disclosure decisions. SEC materiality, state breach notices, FTC matters and player communications belong to your counsel and executives.

Common mistakes

• Treating the engine as a platform, not a dependency. The engine runtime ships in every build. Track its version per title like any other component.
• Forgetting the back catalog. Titles still on sale or still playable online carry their old engines and libraries. If nobody owns them, nobody patches them.
• Scanning manifests instead of lockfiles. Most web, launcher and backend exposure is transitive. An SBOM built from a manifest alone misses the packages a registry advisory names.
• Letting creative tools install anything. Artist and pipeline workstations are high-value targets. An approved source list for plugins and extensions is cheap and effective.
• Ignoring SDKs in child-directed apps. Under COPPA 312.8(c), the analytics or ad SDK in a kids' title is a third party you must vet and get assurances from.
• Keeping evidence in inboxes. Evidence collected through the year is what makes a TPN assessment or a 10-K season short.

FAQ

What is software supply chain security for game studios and media companies?

It is knowing and controlling the third-party code inside the games, apps, players and services you build, and the vendors behind the tools you buy: engines, middleware, SDKs, mods and creator tools, live service dependencies, streaming technology and pipeline software, tied to a patch clock and evidence.

Does the amended COPPA Rule require an SBOM?

No, not by that name. Section 312.8 requires a written information security program with annual risk assessments, safeguards, testing and monitoring, plus written assurances from third parties that handle children's data. An inventory of the SDKs and components in each child-directed build is a practical way to support that program; confirm with counsel what your program needs.

When did the COPPA amendments take effect?

The amended rule was published on 22 April 2025 and took effect on 23 June 2025. The FTC set 22 April 2026 as the compliance date for most of the changes.

How should a studio respond to a game engine vulnerability?

Use your title register to find every live and catalog title built with an affected engine version, check the vendor's advisory for patched versions and any patch tool, decide per title whether to rebuild or patch, resubmit to each store or platform, and record exceptions for titles you cannot fix yet.

Do Apple's SDK rules affect game studios?

Yes, for any studio shipping on iOS. Apple requires a privacy manifest for each listed third-party SDK when you submit a new app or an update that adds one, and signatures when those SDKs are binary dependencies.

Which vendors should a media company ask for an SBOM first?

Start with Critical vendors: engine and core middleware, SDKs inside child-directed apps, payment and identity providers, and vendors whose software touches pre-release content. Ask for SPDX or CycloneDX aligned with CISA's 2026 minimum elements, and say how often you expect updates.

How should a streaming or gaming company respond to an npm package compromise?

Follow CISA's September 2025 recommendations: review dependencies, check lockfiles for affected versions including nested ones, search caches and artifact repositories, pin to known safe versions, rotate developer credentials and enforce phishing-resistant MFA. Then record what you did and when.

Can Safeguard scan unreleased game code without sending it to the cloud?

Yes. Per the docs, the local runner in the Safeguard CLI scans on your own machine and uploads only the SBOM and findings, never source code. On-prem and air-gapped deployment and Zero AI mode are also available.

Much of the exposure in this guide sits in open source packages inside the live services, launchers, web players and pipeline tools that studios and media companies build and ship themselves. For those components, the section below sets out how Safeguard closes the gap between a published fix and a deployed one, and what happens when no fix exists yet.

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 is a real CLI session: ask "fix the lodash CVE in this repo", and the CLI 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 your approval, and pushes nothing. A live services or web player team would run the same flow on its own JavaScript repository after an npm advisory.

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

The second demo sets up the local runner on your own machine, approves it with its device code, and scans from the terminal. It is the route for a studio whose policy, or whose platform agreements, do not allow a cloud service to clone unreleased game code.

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

The third demo is a real Android session: send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. It suits a live operations engineer who is away from a desk during a launch weekend or a live event.

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

Related reading: software supply chain security for media and entertainment, SBOMs for the gaming industry, the 2021 Twitch source code leak, Electron app supply chain security and the polyfill.io CDN supply chain attack.

Quick check

Sources

• Federal Register (govinfo): FTC final rule, Children's Online Privacy Protection Rule (22 April 2025)
• eCFR: 16 CFR 312.8, Confidentiality, security, and integrity of personal information collected from children
• Federal Register (govinfo): SEC final rule, Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure (4 August 2023)
• PCI SSC: Summary of Changes from PCI DSS v3.2.1 to v4.0
• PCI SSC blog: Now is the time to adopt the future-dated requirements of PCI DSS v4.x
• Apple Developer: Third-party SDK requirements
• Trusted Partner Network (TPN)
• NIST SP 800-218: Secure Software Development Framework version 1.1
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• European Commission: Cyber Resilience Act
• Unity: Security advisory for CVE-2025-59489
• CBS News Los Angeles: LA County man agrees to plead guilty to hacking Disney employee's computer (1 May 2025)
• CISA: Widespread supply chain compromise impacting npm ecosystem (23 September 2025)
• Safeguard docs: Policies and Gates
• Safeguard docs: Mitigations
• Safeguard docs: Generate SBOM
• Safeguard docs: Continuous Scanning
• Safeguard docs: Third Party Risk Manager
• Safeguard docs: TPRM Vendor Management
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Monitoring
• Safeguard docs: PCI DSS and connectors
• Safeguard docs: Local Runner
• Safeguard docs: GitHub Actions
• Safeguard docs: Portal Audit Trails
• Safeguard docs: Trust Center setup

To try the flows in this guide, download Safeguard at https://safeguard.sh/download and read the documentation at https://docs.safeguard.sh/docs .

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