Defensive Adversary Emulation with Safeguard Red Team: Scope, Rules of Engagement and ATT&CK

Defensive adversary emulation answers one question: if an attacker used a specific, known behavior inside your environment, would your monitoring see it, and could the exposures you already have be chained into something worse? You answer it safely by limiting the exercise to assets your organization owns and has verified, writing down and signing the rules of engagement before anything active runs, mapping every planned behavior to a MITRE ATT&CK technique with the detection you expect next to it, using harmless signals instead of real attack tooling, and treating every miss as a work item that ends in a fixed exposure, a new or tuned detection, or a recorded risk decision. This post walks through that program design for any security team, then shows how Safeguard's Red Team engine enforces those controls in code.

Key takeaways

• Adversary emulation is a validation exercise, not a discovery exercise. A scanner tells you a weakness exists. Emulation tells you whether the layers built around that weakness would notice and respond.
• Authorization comes first and is written down. Every target must be owned by your organization, verified as owned, and listed on an allow list. Anything not on the list is out of scope by default.
• Rules of engagement are a signed document with named owners, time windows, excluded systems, impact limits, a stop procedure and a communication plan. If you cannot write them down, you are not ready to run anything.
• MITRE ATT&CK gives every planned behavior a shared name and identifier. Map each emulated step to a technique or sub-technique and write the detection you expect before the exercise, not after.
• Use benign, observable signals that prove whether monitoring fires. Real exploit payloads add risk without adding much detection evidence.
• Every result lands in one of a few buckets: alerted, logged but not alerted, not observed, or blocked. Each bucket has a different owner and a different fix.
• Findings only matter if they turn into changes: an exposure removed, an attack path broken, a detection written or tuned, and a retest that proves it.
• Safeguard's Red Team, defensive adversary emulation (GA) emits benign detection canaries mapped to ATT&CK techniques, never ships or runs real exploit payloads, and gates every active step behind signed rules of engagement, verified in-scope targets, rate and blast radius caps, human approval for higher impact steps, a global kill switch and a full audit trail.
• Red Team results land in unified findings (GA) as redteam findings and correlate with SAST and DAST (GA), Runtime Protection (GA) and software composition analysis (GA) findings, so a path that emulation confirms ranks above theoretical risk.

The situation

Most security teams can produce a long list of what is wrong. Vulnerability scans, cloud posture checks, code scanning and dependency analysis each add rows to a backlog. What fewer teams can produce, when an executive or an auditor asks, is evidence that the controls sitting on top of that backlog actually work. The endpoint agent is deployed. The log pipeline ships events to the security information and event management (SIEM) platform. The detection engineering team has a rule library. Nobody has checked, recently and in a structured way, whether a specific behavior in a specific part of the environment produces an alert that a person would see.

The usual answer is an annual penetration test or an outside red team engagement. Both have value, and both are snapshots. The detection gaps in the report are often a paragraph near the end, and nobody reruns the test to prove the fix worked.

There is a second problem that teams rarely say out loud. Offensive testing inside your own network carries real risk. An aggressive scan can take down a fragile legacy service. A test that touches a system owned by a cloud provider, a managed service partner or a customer can create a contractual or legal problem. A tester who drifts out of scope can create an incident that looks exactly like the thing the security team exists to prevent. So security leaders often limit testing to a narrow window and a narrow scope, which makes the results even less representative.

Defensive adversary emulation tries to fix both problems at once. It runs more often, it maps its behaviors to a framework your detection team already uses, it relies on harmless signals instead of real attack tooling, and it wraps every active step in controls that keep it inside the boundary you authorized. The rest of this post explains how to design that program whether or not you use Safeguard.

What defensive adversary emulation is, and what it is not

The vocabulary in this area overlaps, so it helps to separate the activities before planning anything.

Vulnerability assessment finds and lists weaknesses. It answers "what is exposed?" It does not test whether anyone would notice an attacker using those weaknesses.

Penetration testing tries to exploit weaknesses within an agreed scope to show impact. It answers "how far could someone get?" A good test includes detection notes, but the main output is a list of exploitable issues.

Red team engagements are usually objective driven. A small team tries to reach a defined goal while the defenders, often unaware of the timing, respond as they would to a real event. These test people and process as much as technology.

Breach and attack simulation (BAS) runs safe, repeatable simulations of specific behaviors, usually on a schedule, to check whether controls detect or block them. It answers "does this detection still work today?"

Purple teaming puts the people who emulate behaviors and the people who detect them in the same room, or the same channel, working through techniques one at a time. Each step pairs a behavior with the detection that should catch it, so gaps surface immediately and the detection team can tune rules on the spot.

Attack path analysis looks at how known exposures could chain together. A misconfigured identity, a reachable service and a vulnerable dependency might each be medium severity alone and critical in combination. Path analysis is about the chain.

Defensive adversary emulation, as this post uses the term, combines BAS, purple teaming and attack path analysis with one hard constraint: it never executes weaponized exploits. The goal is to validate detection and map chains of existing exposure, not to prove that a payload works. That constraint is what makes it safe to run frequently against production adjacent systems you own.

What it is not:

• It is not a replacement for a skilled human red team. People find creative paths, social engineering angles and business logic flaws that no automated emulation will.
• It is not a license to test systems you do not own. Shared infrastructure, third party services and customer environments are out of scope unless the owner authorizes them in writing.
• It is not proof that a vulnerability is exploitable. A benign canary that goes undetected proves a monitoring gap, not an exploitation path.

MITRE ATT&CK in brief, for planning an emulation

MITRE ATT&CK describes itself as a globally accessible knowledge base of adversary tactics and techniques based on real world observations, and it is open and available to any person or organization at no charge. For emulation planning, its value is a shared vocabulary: a behavior described as an ATT&CK technique means the same thing to the person emulating it, the detection engineer writing the rule and the auditor reading the report.

The core concepts you will use:

• Tactics describe the adversary's goal at a step, the "why". The Enterprise tactics run from Reconnaissance and Resource Development through Initial Access, Execution, Persistence, Privilege Escalation, Stealth, Defense Impairment, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration and Impact. If your rule library still files things under Defense Evasion, check the current Enterprise tactics page: the TA0005 tactic is now named Stealth, and Defense Impairment (TA0112) covers adversaries trying to break security mechanisms, pipelines and tooling so defenders cannot see or trust what is happening. Tactics have identifiers that start with TA, for example TA0001 for Initial Access.
• Techniques describe how an adversary achieves a tactic, the "how". Each has an identifier that starts with T, for example T1059 for Command and Scripting Interpreter.
• Sub-techniques describe a more specific way of carrying out a technique. Their identifiers add a suffix, for example T1059.001 for PowerShell under Command and Scripting Interpreter.
• Procedures are the specific ways real groups or software have implemented a technique, recorded as examples on each technique page.
• Mitigations describe security concepts and controls that can prevent a technique from succeeding.
• Detection strategies, analytics and data components describe how a defender could observe a technique: what logic to apply and which data the environment has to produce for that logic to work. Each technique page links to its detection strategies.
• Groups and software pages connect known threat actors and tools to the techniques they have been reported using.

ATT&CK is organized into matrices for different technology domains: Enterprise, which covers Windows, macOS, Linux, cloud, network, containers and related platforms; Mobile; and ICS for industrial control systems. Most emulation programs start with Enterprise.

MITRE also publishes adversary emulation plans. MITRE calls them prototype documents, built from public threat reports, whose purpose is to let defenders test their networks and defenses more effectively and to create analytics for ATT&CK behaviors rather than detecting a single indicator or tool. They are useful references for how a structured emulation is organized, even if you build your own plan from your threat model. You do not need their command level material to run a defensive program; the structure and the technique mapping are what transfer.

Three habits make ATT&CK mapping useful instead of decorative:

1. Map to the most specific level you can. "Command and Scripting Interpreter" is a broad technique. The detection for one interpreter often looks nothing like the detection for another. If the sub-technique exists, use it.
2. Map the expected detection, not just the behavior. A row that says "T1059.001" tells you what was emulated. A row that says "T1059.001, expected alert from endpoint telemetry rule X, owner Y" tells you what to check.
3. Pick techniques from your threat model, not from the whole matrix. Coverage of every technique is not the goal. Coverage of the techniques that the groups targeting your sector use, on the platforms you actually run, is.

Scope and authorization: the part you cannot skip

Every safe emulation program starts with a clear answer to "what are we allowed to touch, and who said so?" Write the answer down before planning techniques.

Ownership and verification

Only assets your organization owns, or operates under an agreement that explicitly permits testing, belong in scope. Ownership needs to be verified, not assumed. For domains, that usually means a DNS record or file placed by someone with administrative control. For cloud accounts, it means the account sits inside your organization's account structure and the account owner has signed off. For on premise hosts, it means the asset inventory lists your team as owner and the system owner agrees.

Watch for the common traps:

• Shared and managed services. Your tenant on a software as a service product is yours. The provider's infrastructure is not. Testing behaviors against the provider's platform needs the provider's permission and is usually limited by their published testing policy.
• Cloud provider infrastructure. Most cloud providers publish rules on what customers may test inside their own accounts and what needs prior notice. Read them and record which rules apply.
• Third party hosted assets. A marketing site hosted by an agency, a payment page served by a processor or a support portal run by a vendor may carry your brand without being yours to test.
• Acquired companies. Assets from an acquisition can sit in inventory before legal ownership and security responsibility have fully moved. Confirm both.
• Customer environments. Never include them unless the customer has authorized the specific test in writing.

The allow list

Turn verified ownership into an explicit allow list: hostnames, IP ranges, cloud accounts, clusters, applications and identity tenants that are in scope. Everything else is out of scope by default. A deny list on its own is not enough, because new assets appear constantly and a deny list silently includes them.

Record exclusions inside the allow list too. Fragile legacy systems, safety critical systems, regulated data stores and anything under change freeze often belong on an explicit "never touch" list even when you own them.

Who authorizes

Name the people who sign. A typical set includes the security leader who owns the program, the owners of the in scope systems, someone from legal or risk for anything near regulated data, and the operations or site reliability lead who would receive the page if something broke. Their signatures go on the rules of engagement, not in an email thread.

Standards that expect this discipline

You do not have to invent this. NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, exists to help organizations plan and conduct technical security tests, analyze findings and develop mitigation strategies. NIST SP 800-53 Rev. 5 control CA-8 is Penetration Testing, and its enhancement CA-8(2) is Red Team Exercises. If you already map your program to those documents, defensive adversary emulation slots into the same governance.

Rules of engagement: write them, sign them, enforce them

Rules of engagement (RoE) turn the scope decision into operating instructions. A good RoE document is short enough that every participant reads it and specific enough that a stranger could tell whether an action is allowed.

What a rules of engagement document should contain

An illustrative rules of engagement outline

The outline below is a planning template, not a Safeguard file format, and it was not run against any tool. It shows the level of detail that makes an RoE enforceable.

# Illustrative rules of engagement outline (planning template only)
exercise: q4-detection-validation-endpoint-and-identity
version: 3
objective: >
  Confirm that endpoint and identity detections fire for the techniques
  listed below on verified, in scope assets.
authorized_targets:
  - asset_group: corp-workstations-pilot      # verified in asset inventory
  - asset_group: build-runners-staging        # verified, owner signed
  - cloud_account: security-sandbox           # inside org account structure
exclusions:
  - asset_group: payments-production
  - asset_group: medical-device-gateways
  - any_asset_not_listed_above: true
techniques:
  - id: T1059.001
    expected_detection: "endpoint rule: suspicious interpreter launch"
    detection_owner: detection-engineering
  - id: T1087
    expected_detection: "identity analytics: account enumeration"
    detection_owner: identity-security
methods:
  benign_canaries_only: true
  real_payloads: false
  read_only_discovery: true
windows:
  timezone: America/New_York
  allowed: "Tue-Thu 10:00-16:00"
  blackout: ["release-freeze", "quarter-close"]
limits:
  max_requests_per_minute: set-per-target
  max_concurrency: set-per-target
approvals:
  above_low_impact: security-program-owner
stop:
  who_can_stop: [security-program-owner, soc-shift-lead, system-owner]
  conditions: [unexpected-service-degradation, out-of-scope-signal, real-incident]
deconfliction:
  soc_notified: true
  emulation_marker: documented-in-soc-runbook
signatures:
  - role: security-program-owner
  - role: system-owner-build-runners
  - role: legal-risk

Two choices in that outline matter more than they look. First, any_asset_not_listed_above makes the default explicit. Second, each technique carries an expected detection and an owner, so the results map straight to the people who act on them.

Enforcement, not just paperwork

The weakest RoE is the one that lives in a shared drive while the tooling does whatever the operator types. The strongest RoE is enforced by the system that runs the emulation: it refuses to start without a signed document, refuses targets that are not verified and allow listed, enforces the caps, waits for named approval on higher impact steps, records every action and stops everything when anyone with authority pulls the switch. When you evaluate any emulation tooling, ask which of those controls are enforced in code and which depend on operator discipline.

Safety controls that keep emulation defensive

The RoE says what is allowed. These controls make sure nothing else happens.

Benign canaries instead of payloads

A detection canary is an observable but harmless signal that looks, to your telemetry, like the behavior a technique describes. It might create the process, file, network or log artifact a detection should key on, without doing anything harmful. The point is evidence: did the sensor see it, did the pipeline carry it, did the rule fire, did a person get the alert?

Real exploit payloads add very little to that evidence and a lot to the risk. They can crash services, leave artifacts that need cleanup and, if they escape scope, cause the incident you are trying to prevent. A defensive program does not need them.

Read only reconnaissance

Discovery techniques, the ATT&CK tactic for learning about an environment, can be emulated with read only enumeration and mapping against in scope, verified assets. Nothing should change state. If a discovery step would write, delete or reconfigure anything, it does not belong in a defensive exercise.

Rate and blast radius caps

Every active step should be bounded by request rate, concurrency and an overall impact limit. Set caps per target class. A modern web service and a decade old internal application should not share the same limit.

Human approval for higher impact steps

Define a low impact threshold. Anything above it waits for explicit approval from a named person, recorded with time and identity. This keeps the exercise fast for the routine steps and deliberate for the rest.

A global kill switch

One control halts all active emulation, immediately, across every target. Test it before the first exercise. Make sure the SOC shift lead and system owners know it exists and can reach the person who controls it.

A complete audit trail

Record every step with the actor, tenant or environment, timestamp and outcome. The audit trail serves three readers: the detection team reconciling what fired, the SOC deconflicting alerts and the auditor asking for evidence that the exercise stayed inside its authorization.

Deconfliction with the SOC

Your SOC should be able to tell emulation from a real attack without the emulation team on a call. Document the markers in the SOC runbook, agree how an analyst confirms an alert belongs to the exercise, and agree that a real incident always pre-empts the exercise. Do not let "it is probably the red team" become a reason to ignore an alert.

Planning the exercise: from threat model to expectation matrix

With scope, RoE and safety controls in place, plan what to emulate.

Start from the threats that matter to you

Pick techniques from your threat model. Useful inputs include the groups ATT&CK associates with your sector, recent incident reviews, your cloud and platform footprint, and the attack paths your exposure data already suggests. A software company with a large build system should care about techniques that touch build runners, credentials in pipelines and source control. A company that lives in a single identity provider should care about account discovery, valid accounts and token theft behaviors.

Write the expectation matrix

Before the exercise, build a table that pairs each technique with the detection you expect. This is the purple team contract.

The table is illustrative. Your rows should come from your threat model and your actual rule library.

Decide what "pass" means

For each row, agree on what counts as success. Typical outcomes:

• Alerted: the signal reached the SIEM and a rule produced an alert that a person would see in the normal queue.
• Logged, not alerted: the telemetry exists but no rule fired. This is a detection engineering gap.
• Not observed: the telemetry never arrived. This is a sensor, logging or pipeline gap.
• Blocked: a preventive control stopped the behavior. Record whether the block was also visible to the SOC.

Agree up front how long to wait for an alert before calling it missed. Some pipelines batch events, and an unrealistic window creates false gaps.

Running a purple team session

A good session is unhurried. Work one technique at a time.

1. The emulation side announces the technique and target in the shared channel.
2. The canary or simulated behavior runs inside the caps.
3. The detection side checks the SIEM, the endpoint console and any other relevant tools.
4. Both sides record the outcome against the expectation matrix.
5. If the result is a gap, the detection engineer looks at the raw telemetry right away. Often the rule exists but filters too narrowly, or a field name changed after an agent update.
6. If a quick tune is safe, make it, rerun the step and record both results.

Reading results: four kinds of gap, four kinds of owner

Each outcome bucket points at a different fix.

Attack path findings sit beside these. When emulation and exposure data show that several existing weaknesses chain into a path toward something valuable, the fix is usually to break the chain at the cheapest, most reliable point. Removing one misconfigured permission can matter more than patching three medium findings.

How findings feed fixes and detections

This is where most programs lose value. A report full of gaps does nothing until each gap becomes a tracked change.

Turn every gap into a ticket with an owner

Each missed or partially detected technique becomes a work item in the tracker the owning team already uses. Include the ATT&CK ID, the target, the expected signal, what was actually observed, the evidence from the audit trail, and the proposed fix. Link it back to the exercise and the RoE version.

Fix exposures on the path

If emulation confirms a path, the exposures along it move up the priority list. A reachable, exposed weakness on a confirmed path deserves faster attention than the same weakness in isolation. Track the fix through the same remediation workflow as any other vulnerability, so it is not a side list owned by the red team.

Write detections as code, with tests

When a rule is new or tuned, store it in version control with the ATT&CK technique in its metadata. Add a test that uses the same benign signal the emulation produced. Now the emulation step doubles as a regression test for the rule.

Retest to close

A gap is closed when a rerun of the same technique against the same target produces the expected outcome. Until then it is open, regardless of what the ticket says. Schedule retests automatically where you can.

Track coverage over time, without vanity metrics

Keep a coverage view: which techniques from your threat model have been emulated, against which targets, with what latest outcome and when. Use it to plan the next exercise and to answer "how do you know your controls work?" with evidence. Avoid reducing it to a single score.

Feed results back into policy

Some results should change policy, not just a rule. If a class of exposure keeps appearing on confirmed paths, set a policy so new instances of it are caught earlier, in the pipeline or at deployment, rather than found by the next emulation.

How often should we run adversary emulation?

Match cadence to change. Detections that depend on fast changing telemetry, such as endpoint agents, identity platforms and build infrastructure, deserve frequent automated validation, because an agent update or a schema change can silently break a rule. Full purple team sessions with people in the loop fit a slower rhythm, or follow a significant change such as a new SIEM, a new identity provider or a large incident.

Is it safe to run emulation against production?

It can be, if the controls above are real. Benign canaries, read only discovery, caps, approval thresholds, a working kill switch and SOC deconfliction are what make production adjacent testing acceptable. Systems on your exclusion list stay excluded. If any of those controls depends only on operator discipline, start in a staging environment that mirrors production telemetry and move forward once you trust the tooling.

How do we prove the exercise stayed in scope?

With the audit trail and the RoE together. An auditor or a system owner should be able to pick any recorded step and see who triggered it, against which verified target, at what time, under which signed RoE version and with what outcome. If the tooling blocked an out of scope action, that block should be in the log too.

How Safeguard does this

Safeguard's Red Team, defensive adversary emulation (GA) is a defensive capability by design. It emulates adversary behavior to validate that your detections fire and to map how an attacker could chain your existing exposures, without executing weaponized exploits. The Safeguard documentation is direct about this: the engine emits benign detection canaries that map to MITRE ATT&CK techniques, it does not ship, download or run real exploit payloads, and it will not attempt to gain unauthorized access.

What the engine does

The documentation lists five capabilities:

The safety kernel

Safeguard calls the set of controls that gate every active step the safety kernel. The documentation states these controls are enforced in code, not offered as interface conveniences:

• Signed rules of engagement. Active emulation cannot start without a signed RoE that defines what is authorized.
• Verified and in scope only. Targets must be ownership verified and fall inside an allow listed scope. Out of scope actions are blocked and logged.
• Rate and blast radius caps. Mandatory limits bound request rate, concurrency and impact.
• Human approval for high impact steps. Anything above a low impact threshold needs explicit human sign off before it runs.
• Global kill switch. A single control halts all active emulation immediately.
• Full audit trail. Every step is recorded with actor, tenant, timestamp and outcome.

Read that list against the RoE table earlier in this post: allow list and exclusions, impact limits, approval thresholds, stop conditions and evidence handling each have a control that enforces them.

Setting it up

The Red Team engine is turned on by an administrator through a feature flag (scanner:redteam) that is enforced server side, so a tenant that has not enabled it cannot run it. Once it is enabled, the documented flow has four steps:

1. Register and verify the assets in scope. Only ownership verified assets can be targets.
2. Upload a signed rules of engagement document. Without it, active emulation does not start.
3. Choose the techniques or paths to exercise and the safety caps. This is where your expectation matrix becomes configuration.
4. Review results in the unified findings view, correlated with your other engines.

The docs describe that flow, not a specific file format for the RoE, so keep your own signed document as the source of record and upload it as the engine requires.

Where results go: unified findings

Red Team results do not sit in a separate report. They flow into Safeguard's unified findings (GA) model with finding_type set to redteam, and correlate with findings from SAST and DAST (GA), Runtime Protection (GA) and software composition analysis (GA). The documentation's point is prioritization: a path that is reachable, exposed and exploitable, and confirmed by emulation, ranks above theoretical risk.

A few details from the unified findings documentation help when you go looking for results:

• Findings for a project live in its Findings tab. Red Team results appear in the Application Security panel further down that tab, on their own Red Team sub-tab, rather than as an option in the Scanner dropdown at the top.
• That sub-tab only appears when the tenant has the scanner:redteam feature flag enabled. If you cannot see it, check the flag before assuming the engine produced nothing.
• Because every engine shares one model, findings share correlation keys, which is what lets a Red Team path sit next to the code, dependency and runtime findings for the same system.
• Every finding is scoped to its tenant and organization end to end.

In practice that changes the conversation with engineering teams. A dependency vulnerability on its own is one of many rows. The same vulnerability on a confirmed attack path, with runtime signals showing the code is loaded, is a much easier case for a fix this sprint.

Turning findings into gates

The Red Team documentation points to guardrails and enforcement (GA) for using validated findings as policy gates. Safeguard policy gates take one of three actions: Block, Warn or Notify. When a team needs to proceed despite a gate, approval goes through an exception, which records who approved it and why. That lets a class of exposure that keeps showing up on confirmed attack paths become a gate in the pipeline, so new instances are caught before they ship instead of discovered by the next emulation.

Getting gaps to the right people

Gaps should land where the owning team already works. The Jira integration (GA) creates Jira issues for the findings and work you send to it, updates them and moves them through your workflow using the status mapping you set. The Linear integration (GA) creates Linear issues for the findings you send and comments on them as they change. Chat integrations such as Slack (GA) and Microsoft Teams post notifications for new findings, scan results and alerts to a channel. A missed detection becomes an issue for detection engineering; an exposure on a confirmed path becomes an issue for the owning service team.

Validating AI guardrails

If your products include LLM features, the guardrail validation harness applies the same defensive pattern. It sends benign test cases that probe prompt injection and jailbreak resistance to confirm your guardrails hold, and the results land in the same unified findings view. This sits naturally next to AI Gateway (GA) and AI security posture management (GA) if you use them, but the harness itself is about validating whatever guardrails you have.

A worked flow, end to end

Here is how the program in this post maps onto Safeguard for a team validating endpoint and identity detections on a pilot group and staging build runners.

1. The security program owner gets written sign off from system owners and legal, and records it in a signed RoE that lists the pilot workstation group, the staging build runners and the security sandbox account, with payments and medical device systems explicitly excluded.
2. An administrator enables the Red Team feature flag for the tenant.
3. The team registers the pilot group, build runners and sandbox account and completes ownership verification. Anything not verified cannot be targeted.
4. They upload the signed RoE.
5. They choose techniques from their expectation matrix, set the caps for each target class, and leave anything above the low impact threshold behind human approval.
6. The SOC shift lead is told the exercise window and has the kill switch contact.
7. The engine emits benign canaries for each chosen technique. Detection engineering watches the SIEM and records the outcome against the matrix.
8. Results land in unified findings as redteam findings, correlated with the code, dependency and runtime findings Safeguard already has for those systems.
9. Gaps become tickets through the team's tracker integration. Exposures on confirmed paths enter the remediation workflow. New detection rules go into version control with the ATT&CK ID and a test.
10. The team reruns the same techniques after the fixes. A gap closes when the rerun produces the expected outcome. The audit trail records both runs.

What Safeguard Red Team does not do

• It does not run real exploit payloads, download attack tooling or attempt unauthorized access. If you need exploitation evidence, that is a penetration test with its own authorization.
• It does not target assets that are not ownership verified and inside the allow listed scope. It blocks and logs out of scope actions.
• It does not start active emulation without a signed rules of engagement document.
• It does not replace a human red team. It complements human testing with frequent, repeatable, controlled checks.
• It does not write your detection rules for your SIEM. It shows which techniques went unseen so your detection engineers can fix them.
• It is not a social engineering or phishing simulation service.

Common mistakes

Testing what is easy instead of what matters. Teams often start with the techniques their tooling supports best. Start from the threat model and accept that some important techniques need more planning.

Mapping only to tactics. "We covered Lateral Movement" says little. Map to techniques and sub-techniques, because detections are written at that level.

Skipping the expectation matrix. Without an expected detection per technique, the debrief becomes a debate about whether an alert that fired somewhere counts.

Letting scope drift. An extra subnet added mid exercise "because it is ours anyway" is how out of scope incidents start. Changes to scope mean a new RoE version and new signatures.

Not telling the SOC. An exercise the SOC does not know about wastes analyst time and can mask a real incident. Deconfliction is part of the design.

Treating "logged" as "detected". If telemetry exists but nothing alerts, the technique was not detected. Be strict.

Filing a report instead of tickets. A PDF is not a remediation plan. Every gap needs an owner, a ticket and a retest.

Never retesting. Rules regress after agent updates, schema changes and pipeline migrations. A gap closed six months ago may be open again.

FAQ

What is defensive adversary emulation?

Defensive adversary emulation reproduces known attacker behaviors in a controlled way to check whether your detections fire and how your existing exposures could chain together, without running real exploit payloads. It combines breach and attack simulation, purple teaming and attack path analysis inside a signed, enforced scope.

Does Safeguard Red Team run real exploits?

No. According to the Safeguard documentation, the engine emits benign detection canaries mapped to MITRE ATT&CK techniques and does not ship, download or run real exploit payloads. It will not attempt to gain unauthorized access.

Which targets can Safeguard Red Team touch?

Only assets you have registered and ownership verified, inside an allow listed scope. Out of scope actions are blocked and logged.

What happens if no rules of engagement document is uploaded?

Active emulation cannot start. The documentation lists a signed rules of engagement document as a precondition for any active step.

How are Red Team results mapped to MITRE ATT&CK?

The benign canaries the engine emits are mapped to ATT&CK techniques, and purple teaming pairs each simulated technique with the detection you expect, so a gap shows up as a technique that fired with no alert.

Where do Red Team findings appear?

In Safeguard's unified findings view, marked as redteam findings and correlated with SAST, DAST, runtime and SCA findings.

Can Red Team findings block a release?

Validated findings can feed Safeguard policy gates through guardrails and enforcement. Gates take Block, Warn or Notify actions, with approvals handled through exceptions.

Does it test AI and LLM guardrails?

Yes. A guardrail validation harness probes prompt injection and jailbreak resistance with benign test cases to confirm your guardrails hold.

Related reading

• Red Team: defensive adversary emulation mapped to MITRE ATT&CK
• How to scope a penetration test and define rules of engagement
• What is MITRE ATT&CK?
• MITRE ATT&CK technique guides for defenders
• Purple team exercises with a supply chain focus
• Red team vs blue team
• MITRE ATT&CK v18 detection strategies and analytics

Emulation tells you which exposures sit on a path that matters and which detections need work. For the exposures that come from open source dependencies and container images you build, the next step is getting the fix shipped quickly, including when upstream has not released one 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

These interactive demos show the Safeguard surfaces your team would use around a Red Team exercise.

Safeguard CLI in action

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

Claude with Safeguard

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

Safeguard desktop app in action

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

Quick check

Sources

• Safeguard Docs, Red Team (Defensive Adversary Emulation): https://docs.safeguard.sh/docs/red-team
• Safeguard Docs, Unified Findings and Feature Flags: https://docs.safeguard.sh/docs/unified-findings
• Safeguard Docs, Guardrails and Enforcement: https://docs.safeguard.sh/docs/guardrails-enforcement
• Safeguard Docs, Integrations: https://docs.safeguard.sh/docs/integrations
• MITRE ATT&CK: https://attack.mitre.org/
• MITRE ATT&CK, Enterprise tactics: https://attack.mitre.org/tactics/enterprise/
• MITRE ATT&CK, Command and Scripting Interpreter (T1059): https://attack.mitre.org/techniques/T1059/
• MITRE ATT&CK, Adversary emulation plans: https://attack.mitre.org/resources/adversary-emulation-plans/
• MITRE ATT&CK, PowerShell (T1059.001): https://attack.mitre.org/techniques/T1059/001/
• MITRE ATT&CK, Account Discovery (T1087): https://attack.mitre.org/techniques/T1087/
• MITRE ATT&CK, Unsecured Credentials (T1552): https://attack.mitre.org/techniques/T1552/
• MITRE ATT&CK, Remote Services (T1021): https://attack.mitre.org/techniques/T1021/
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment: https://csrc.nist.gov/pubs/sp/800/115/final
• NIST SP 800-53 Rev. 5: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
• NIST SP 800-53 Rev. 5 control catalog (OSCAL), CA-8 and CA-8(2): https://github.com/usnistgov/oscal-content