How T1195 supply chain compromise gets into your environment
T1195 Supply chain compromise is the ATT&CK technique in which an adversary gets into your environment by tampering with something you already trust before it arrives: a software product, a update, a build dependency or a piece of hardware. It matters because it sits under Initial Access (TA0001), which MITRE defines as "The adversary is trying to get into your network." For a SOC lead, the difficulty is that the entry point looks like normal, authorized activity: a signed update installed by a scheduled job, or a package pulled by a build pipeline. This page maps detection and response to Enterprise ATT&CK 20.0, so every rule and test you write should name that version.
ATT&CK describes three sub-techniques under T1195. At a high level, one covers compromise of software dependencies and development tools, where the tainted component is a library, plugin or tool that your builds consume. Another covers the software supply chain itself, meaning the products and updates you install from a vendor or distribution channel. The third covers the hardware supply chain, where the tampering happens in components or devices before deployment. Each one travels a different trust path and leaves different evidence, so the telemetry you need differs too. A practical first step is to list which of your Linux, Windows, macOS and SaaS platforms pull packages, updates or firmware from outside your control, and to confirm the exact sub-technique IDs in the Enterprise ATT&CK 20.0 STIX bundle before you map detections to them.
The decision that matters most is which trust paths you choose to monitor first. Software and update channels usually produce the most usable signal because they generate process, file and network events you can baseline, while hardware provenance is often verified at procurement and receiving rather than in the SIEM. Ask your platform and build teams which sources they can log and retain, and confirm that your detection content is tied to a specific ATT&CK release. MITRE has renamed, deprecated and revoked techniques between releases, so pinning your mappings to a version keeps the coverage claim accurate when the framework changes. The ATT&CK updates page is the place to check what has changed since your last review.
Which telemetry reveals supply chain compromise
This table maps the six ATT&CK data components most referenced for Initial Access to the platforms in scope for T1195, with the signal to look for and the open-source collector to use. Read each row as a starting point for your analytics, then confirm coverage in your own environment before relying on it. The main takeaway is that SaaS coverage depends on the application audit logs your organization can export, so confirm that first.
| Data component | Linux and Windows endpoints | macOS and build infrastructure | SaaS and identity providers |
|---|---|---|---|
| Process Creation (DC0032) | Watch for build tools, package managers or updaters spawning unexpected child processes or running from unusual paths. Collect with Wazuh agents or Velociraptor. | Monitor build agents and installers for unexpected parent-child relationships and unsigned helper binaries. Collect with Wazuh agents or Velociraptor. | Not applicable as a direct source. Use the audit logs of CI and SaaS admin consoles instead, and confirm export options with the vendor. |
| Network Traffic Flow (DC0078) | Flag software update or dependency fetches to destinations outside the approved vendor and mirror list. Collect with Zeek conn logs. | Flag build runners contacting new update or package hosts. Collect with Zeek conn logs or Suricata flow records. | Flag connections from integration service accounts to unexpected SaaS tenants or regions. Collect with Zeek at egress points. |
| File Creation (DC0039) | Alert on new or modified binaries, libraries or scripts written by updaters outside the expected change window. Collect with Wazuh file integrity monitoring or Velociraptor. | Watch for unexpected writes to application bundles, launch agents or installer caches. Collect with Wazuh file integrity monitoring. | Not applicable on the SaaS side. Track artifact and package repository uploads through the platform's audit events, if exportable. |
| Network Connection Creation (DC0082) | Record which hosts open outbound connections to software repositories and update servers, and compare them with an approved baseline. Collect with Wazuh or Velociraptor. | Compare build and developer machine connections with an allow list of artifact registries. Collect with Velociraptor. | Confirm whether the identity provider or SaaS exposes connection or session events that can be correlated with downstream activity. |
| Application Log Content (DC0038) | Review package manager, updater and CI logs for changes in source, signing key or checksum. Collect with Wazuh log collection. | Collect build system logs showing changed pipeline steps or new dependencies. Collect with Wazuh log collection. | Key row for SaaS. Coverage depends on the application audit logs the client can export. Confirm export format, retention and fields with each vendor before scoping. |
| Network Traffic Content (DC0085) | Inspect content of update traffic where decrypted or proxied, and look for hash or signature mismatches. Collect with Zeek and Suricata on mirrored or proxied segments. | Inspection is limited where traffic is encrypted end to end. Use Suricata rules on proxy egress where policy allows. | Limited by TLS. Rely on application audit logs and identity provider logs rather than payload inspection. |
Detection logic for software that behaves unexpectedly after an update
Software supply chain compromise usually shows up as a trusted update or build component doing something it does not normally do. The four detections below watch the process, network, file and SaaS administration layers around that update path. Each one needs a baseline agreed with the client before it is tuned, because scheduled patching and approved vendor changes generate most of the noise.
Unexpected child processes from package managers
Package managers, configuration management agents and update services should launch a narrow, known set of child processes. Alert when a package manager or update agent spawns a shell, a scripting interpreter or a download utility that is absent from the agreed baseline for that host group. Tune by host role, since build servers and workstations differ. Expect false positives from scheduled patch windows, post-install scripts that legitimately call interpreters, and vendor agents that were upgraded. Confirm each exception with the change owner and record it with a ticket reference.
Outbound connections to new destinations
Build hosts and update agents normally contact a short list of repositories, mirrors and vendor endpoints. Flag connections from these hosts to destinations never seen in the previous baseline window, especially when the first connection follows a dependency or package change. Set the baseline window and the allowlist with the client, and review domains that resolve to rotating infrastructure separately. Expect false positives when a vendor adds a CDN hostname, when a mirror moves, or when a new region is onboarded. Require a named owner to approve each new destination before it joins the allowlist.
New binaries in trusted install paths
Newly created executables or shared libraries in system install directories, such as those used by package managers, deserve review when no install or update job is running. Compare file creation events in those paths against the package manager's own install records and flag files that match no package. Tune the logic by excluding known install windows and by hashing new files for comparison against the vendor's published values where the vendor provides them. Expect false positives from rebuilds, container image layers and local developer tooling. Confirm the expected write locations with each platform owner.
SaaS admin changes to integrations
In SaaS platforms, a compromised update often arrives through a newly granted OAuth application, a changed integration scope or a new API token. Alert on administrator actions that add or re-consent OAuth apps, widen permissions, or create service credentials outside a change window. Thresholds should reflect how often the client approves integrations, so agree a weekly or per-change-window expectation before setting alert levels. Expect false positives from planned onboarding, vendor-initiated re-consent after an upgrade and help desk actions. Require a change ticket for every high-privilege grant.
How to baseline trusted update paths before you alert
A detection for T1195 Supply chain compromise only fires usefully when you already know what normal looks like. Before writing any alert, agree with the client which hosts, package repositories, update servers, code signing services and vendor domains are expected to deliver software into the environment. Treat this list as a controlled asset with a named owner, because a supply chain alert that cannot distinguish a vendor's signed update from an unexpected binary will either fire constantly or be ignored. Confirm the inventory with the teams that operate each path, including the platform team, the application owners and any managed service provider, since shadow update sources are common in self-hosted estates.
For each trusted path, record its normal behavior as observed in your own environment rather than as assumed from documentation. Capture the parent and child process relationships that typically occur during an update, such as which package manager or updater spawns which installer, the destination hostnames and ports the update client contacts, and the file locations where new artifacts are written. Collect this over a representative window that includes at least one full update cycle, and store the result as a versioned baseline file alongside the detection rules. Telemetry sources such as Process Creation, Network Traffic Flow and File Creation can then be compared against this record. Ask each vendor to confirm its update domains and signing practices in writing, because these change without notice.
Version the baseline against the ATT&CK version your detections target, which for these pages is Enterprise ATT&CK 20.0. Record the version in the baseline file header and in the detection rule metadata so that an analyst can tell which mapping was intended. Releases can rename, deprecate or revoke techniques and sub-techniques, so recheck every T1195 mapping whenever MITRE publishes a new version, using the MITRE ATT&CK updates page as the starting point. Reconcile your baseline with each vendor change and each ATT&CK release on a fixed review cadence agreed with the client, and assign a named approver for any change that adds a new trusted source.
How to validate that the T1195 detection fires
This sequence proves that each T1195 analytic fires, with the expected fields, in a private cyber range before any detection is trusted in production. It ends with a tuning review and a regression schedule tied to the ATT&CK version the detections target.
Confirm scope and written authorization
The security lead and the platform owner agree in writing which systems, Linux, Windows, macOS and SaaS tenants, are in scope for the exercise, which sub-techniques are covered, and who may touch which logs. The authorization names the cyber range or lab, the test window and the people who can stop the exercise. Done means a signed scope document exists and every analytic under test is listed against a specific ATT&CK version, so the mapping is not ambiguous later. Ask your provider to confirm in writing what is included in the scope before any work starts.
Define the benign test artifact
The team agrees on a harmless test artifact that stands in for a tampered update, a modified package or a changed vendor component. The artifact carries a unique marker so it can be found in telemetry and removed afterward. The purpose is to exercise the detection path, not to deliver any working malicious payload. Done means the artifact, its marker and its removal procedure are documented and reviewed by the detection engineer and the range operator, and the artifact has been checked to contain nothing harmful.
Replay the behavior class without commands
The range operator reproduces the behavior class described by each T1195 sub-technique, such as a software update that loads an unexpected component or a SaaS integration that changes its permissions, using a scripted or pre-recorded event replay rather than live attacker commands. Process Creation, Network Traffic Flow and File Creation events are generated in the lab so the analytic logic is exercised. Done means the replay log records the time, host, account and marker for each event, so the team can match every expected detection to a known input.
Check each analytic produces its expected alert
The detection engineer reviews the Wazuh or SIEM alert queue for each analytic and confirms that the expected rule fired for each replayed event. Where an analytic depends on a data component such as Process Creation (DC0032), File Creation (DC0039) or Network Traffic Flow (DC0078), the engineer confirms that the source actually delivered that component. Done means a table lists each analytic, the event it should match, the alert identifier and a pass or fail result, with any gaps logged as defects.
Record time to alert and populated fields
For every alert that fires, the team records the time between the replayed event and the alert appearing in the console, along with whether the expected fields are populated, such as host, user, parent process, hash, source and destination address and SaaS tenant identifier. Missing or empty fields are treated as findings because responders depend on them during triage. Done means each alert has a recorded latency and a completed field checklist, and any analytic that is slow or incomplete has a named owner for correction.
Log false positives from normal activity
The team runs the same analytics against a window of routine, legitimate update and integration activity in the range so that expected noise is measured rather than guessed. Each alert raised by normal behavior is logged with the rule, the cause and a proposed exclusion or threshold change. Done means a false-positive register exists for the exercise, and no exclusion is accepted without a written reason, the affected asset and a review date set by the detection owner.
Run the tuning review and set regression
The detection engineer, the platform owner and the responder meet to review results, decide on tuning changes and confirm which fixes are ready for production. Each analytic is then tied to the ATT&CK version it targets, and the team sets a regression schedule that reruns the replay whenever MITRE publishes a new Enterprise release, since releases can rename, deprecate or revoke techniques. Recent releases include v18 (October 28, 2025), v19 (April 28, 2026) and v20 (October 13, 2026), and the team should check the ATT&CK updates page for later changes. Done means the signed review record, the tuned rule set and a dated regression calendar are stored with the detection documentation.
Preventive controls that narrow the supply chain attack surface
T1195 succeeds when a trusted update, package, or integration path carries malicious code into the environment. The controls below reduce how often that path can be abused and how far an abused path can reach, so detection has fewer surprises to cover.
Controlled patch channels
Update Software (M1051) asks you to define exactly where software updates come from, who approves them, and how they are staged before production. Keep a short list of approved repositories, mirrors and signing sources, and block direct pulls from anywhere else. Ask each publisher which update channels it signs, how it publishes signing keys, and how customers verify a release. Record which versions are running so you can tell quickly whether a compromised release reached you.
Verified update sources
Before an update is installed, confirm its integrity against a signature or checksum that the publisher provides through a separate, trusted channel. Where a platform offers no signing, treat that as a risk to record and compensate for with staging, hash comparison and change review. Automated updaters should not accept unsigned payloads. Confirm with each software publisher which verification steps it supports and how those steps are documented for your environment.
Tight service and integration accounts
User Account Management (M1018) covers the accounts that build pipelines, sync tools and vendor integrations use to reach your systems. These accounts often hold broad rights and rarely get reviewed. Give each one a named owner, the narrowest permissions it needs, and scheduled access reviews. Remove accounts that a vendor or project no longer uses, and rotate credentials after any vendor change of personnel or tooling.
Limit blast radius with segmentation
Network Segmentation (M1030) is also mapped to Initial Access in ATT&CK 20.0. Place build hosts, update servers and third-party integrations in zones that cannot reach production data stores without an explicit allow rule. A compromised update then has fewer paths to spread. Test the rules with your own traffic flows before enforcing them, so you do not break the software that depends on them.
Sandbox newly installed components
Application Isolation and Sandboxing (M1048) is also mapped to Initial Access in ATT&CK 20.0. Run new or recently updated components under restricted privileges, with limited file system and network access, before granting them wider rights. This gives you a controlled window in which unexpected process creation or outbound connections are visible and contained. Ask each publisher which isolation features its product supports and which of them need extra configuration.
What the SOC does in the first hours after a supply chain alert
The first decision is whether the alert describes a supply chain event or an approved update. Analysts should compare the flagged artifact, package, or integration against the change record, the vendor's published release notes, and the signing or hash information the vendor provides, and confirm which of these the client's own environment can actually verify. If the artifact cannot be tied to an approved change, treat it as suspect until proven otherwise. Confirm with the owning platform or engineering team who authorized the change, and record the answer with a timestamp so the decision can be reviewed later.
Containment should isolate affected hosts, build runners, or SaaS tenant connections without wiping them. Pulling a host off the network or revoking an integration token is usually reversible, but reimaging or deleting a build agent is not. Before any containment step, capture volatile state the playbook requires, preserve the suspect binary or package and its hash, and export the relevant logs from the SIEM and from the platform's own audit trail, since those retention windows may be shorter than the investigation. Client incident response playbooks and legal hold rules decide the exact sequence, so the SOC should confirm those owners before acting.
Scoping is usually the hardest step. The team needs an inventory of every system that pulled, built, deployed, or ran the suspect artifact, including container images, CI/CD jobs, package mirrors, and third-party SaaS integrations that hold tokens to the affected service. A useful starting question is which consumers had the artifact available during the exposure window, which the team should answer from build logs and deployment records rather than from memory. Ask the platform owner for a current inventory of pipeline identities and integration credentials before the incident starts, because reconstructing that list under pressure is where scope usually gets missed.
How to rehearse T1195 detection in a private cyber range
The range for Unix-like hosts is a private, isolated network with a SIEM, Wazuh agents on sample Linux and macOS endpoints, a Zeek or Suricata sensor on the segment that carries update traffic, and a mock update server that serves signed and unsigned package versions. The facilitator uses this setup to test whether the team can tell a legitimate update from one that has been tampered with. In an illustrative scenario, a package on a build host is replaced with a new version, and the first clue is a process spawned by the package manager that the team has never seen before.
- Suspect update inject: The facilitator publishes a modified package to the mock update server. Responders must compare the package hash and signing metadata against the vendor's published values.
- Unexpected outbound connection inject: A host that normally contacts only the internal mirror opens a session to an unlisted external address. Zeek connection logs or Suricata alerts should show the destination and timing.
- Process lineage inject: A package post-install step launches a shell or interpreter. Wazuh process telemetry should show the parent chain back to the update tool.
- Alert timing check: Record the minutes between the inject and the first alert, and between the alert and the first analyst acknowledgment.
After the exercise, check whether the team isolated the affected host without disrupting unrelated builds, whether the handoff from triage to incident lead was documented, and which lessons changed the update approval workflow.
The Windows range uses the same isolated network, with Wazuh agents on sample workstations and servers, Windows event telemetry forwarded to the SIEM, and a mock software distribution service that pushes an updated installer. Windows exercises tend to surface gaps in process creation logging and in the handling of signed binaries, so the facilitator should confirm which audit settings are active before the session. In an illustrative scenario, an installer that carries a valid but unexpected signature is pushed to a pilot group, and the team must decide whether the signature alone is enough to trust it.
- Suspect update inject: The facilitator pushes an installer with a signature from an unfamiliar certificate. Responders check the certificate chain and compare the file hash against the vendor's advisory.
- Unexpected outbound connection inject: The installed component contacts a domain that is not in the approved list. Suricata or Zeek records should capture the DNS query and the connection.
- File creation inject: The installer drops an executable into a startup or service path. File creation telemetry should flag the path and the writing process.
- Scope and handoff check: Measure how quickly responders identify other endpoints that received the same package.
After the session, confirm that the team isolated only the affected group, that containment decisions were recorded with timestamps, and that the lessons captured include changes to signing trust and deployment approval.
The SaaS range uses a sandbox tenant or a test workspace with audit logs forwarded to the SIEM, a simulated identity provider, and a mock marketplace or integration catalog. The facilitator focuses on the supply chain path that many organizations overlook: a third-party integration or app that receives a new permission after an update. Confirm with each SaaS vendor which audit events are available and how long they are retained before you design the inject, because some events may only be visible in the vendor console.
- New integration grant inject: The facilitator adds an application to the sandbox tenant with broader scopes than the previous version. Audit log events should show who approved the grant and when.
- Suspect update inject: A connector changes its API calls after an update. Application log content should show the new endpoints or methods being called.
- Unexpected outbound connection inject: The connector sends data to an external API that is not in the approved integration list. Network flow records or proxy logs should show the destination.
- Revocation timing check: Measure the time between the first alert and the revocation of the token or grant.
After the exercise, verify that the team revoked the grant without breaking business-critical integrations, that the approval owner was contacted, and that the lessons captured include a review cadence for third-party app permissions.
Questions SOC leads and detection engineers ask about T1195
How do I separate approved vendor updates from malicious ones in my logs?
Start by building an inventory of expected update channels, signing authorities and install paths for each vendor, then alert on anything that falls outside that baseline. Approved updates should come from known hosts, run under the expected package manager or updater process, and match a change ticket or maintenance window. Treat a valid signature alone as insufficient, because a compromised upstream can still produce a correctly signed artifact. Correlate Process Creation events with File Creation and Network Connection Creation records so that an update that spawns an unexpected child process or writes outside its usual directories stands out for review.
Which ATT&CK data components should my detection team prioritize first?
Begin with Process Creation (DC0032), File Creation (DC0039) and Network Traffic Flow (DC0078), since these are the data components most often referenced by detection strategies for Initial Access techniques and their sub-techniques in Enterprise ATT&CK 20.0. Process Creation shows what a trusted updater or build tool launches, File Creation shows what it writes to disk, and Network Traffic Flow shows where it connects. Add Network Connection Creation (DC0082) once endpoint coverage is stable. Confirm the mapping against the version you target, because releases can rename or deprecate content, and check the MITRE ATT&CK updates page for changes before each detection review.
How should I handle SaaS integrations that offer only limited logging?
Inventory every third-party application with OAuth grants, API tokens or marketplace connections into your identity provider and SaaS tenants, then record the owner, scopes and business purpose for each. Where the vendor exposes audit logs, ingest them into your SIEM and alert on new integrations, scope expansions and token use from unfamiliar addresses. Where logging is thin, compensate with strict approval workflows and periodic access reviews, and ask the vendor in writing which events are available, how long they are retained and whether they can be exported. Document any gap as a residual risk so that the decision is visible to the risk owner.
How often should I retest supply chain detections after an ATT&CK release?
Retest whenever a release changes a technique, sub-technique or mapped data component that your detections depend on, and at minimum review the mapping after each published version. ATT&CK v18 replaced detections in technique pages with detection strategies and analytics, and later releases, including v19 and v20, can rename, deprecate or revoke content, so a detection that worked before may now reference retired logic. Record the ATT&CK version your rules target in each detection's metadata, rerun validation in your cyber range against the updated mapping, and track the cadence in your change process. The exact retest frequency is a policy decision for your organization, so agree it with your detection engineering and audit owners.
How do I avoid alert fatigue during vendor patch windows?
Scheduled patch windows produce predictable bursts of process and file activity, so define them as known maintenance periods in your SIEM and tie suppression to specific hosts, update tools and change identifiers rather than blanket time ranges. Keep the suppression narrow: a patch window should not silence network egress to unknown destinations or child processes launched by a package manager outside its expected tree. Route suppressed events to a lower-priority queue where they are sampled, and review the rules after each window. Test this behavior in a private cyber range by replaying a normal update and a deliberately unusual one, so you can measure whether the rule separates them.
Which mitigations should I confirm are in place before relying on detection alone?
Two mitigations map most directly to T1195: Update Software (M1051) and User Account Management (M1018). Update Software covers how you verify, stage and deploy patches so that vendor updates are tested before production, while User Account Management limits which accounts and service identities can install software, change build pipelines or approve integrations. Confirm with your platform team that software repositories, artifact stores and CI/CD service accounts follow least privilege, that multi-factor authentication protects administrative access where supported, and that exceptions have named owners. Detection is most useful when these controls reduce how often an unexpected change can occur at all.
Can my internal team run these detection exercises without outside help?
Many organizations with an established SOC and detection engineering function can run basic exercises themselves, using a lab that mirrors their Linux, Windows and SaaS telemetry sources. The work usually involves building a test environment, replaying benign and suspicious update activity, confirming that the expected events reach the SIEM, and documenting results. Where the team lacks time, lab capacity or independent review, a fixed-scope engagement with DeployOpen can plan and run the exercise in a private cyber range inside your environment, with written scope and deliverables agreed beforehand. Ask any provider to state which tools, data sources and versions they will test against.
How DeployOpen builds T1195 detections and range exercises
DeployOpen works on T1195 Supply chain compromise as a fixed-scope engagement inside your own environment, starting from the telemetry you already collect. The work turns the technique into detection logic, validation evidence and response runbooks that your team can operate after handover.
How we scope
- Confirm which software sources, build pipelines and third-party update channels fall inside the written scope.
- Inventory the Linux, Windows, macOS and SaaS telemetry available for process, network flow and file creation events.
- Agree the ATT&CK version the detections will target, with sub-technique coverage listed explicitly in the scope document.
How we build
- Write detection logic in open formats such as Sigma rules, mapped to the relevant ATT&CK data components and detection strategies.
- Deploy and tune collection in Wazuh, Zeek, Suricata or Security Onion, as agreed, inside the client's own infrastructure.
- Test detections against defined benign update and package activity to measure false positives before they reach production alerting.
How we hand over
- Deliver detection rules, configuration files and validation results with the ATT&CK version and data sources stated.
- Provide response runbooks covering triage of unexpected update activity, containment steps and evidence preservation.
- Run a cyber range exercise in a private range so your team can rehearse detection and response before go-live.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, defined in a separate written agreement.
- Review detections when ATT&CK releases rename, deprecate or revoke techniques that affect the T1195 mapping.
- Ask us to confirm scope, deliverables and timelines in writing before any work starts; quotes follow from that written scope.
