We attack ourselves, so no one else can.
Our Purple Team stress-tests merlon's defences through controlled attack simulation and validates every update before it ships — so protection is proven, not assumed. They are the final security gate between a change and production, and nothing crosses it unverified.
Initial Access
Execution
Persistence
Priv Escalation
Defense Evasion
Exfiltration
Close the gap between "protected" and "proven"
"The Purple Team exists to close the gap between 'we think we're protected' and 'we've proven it.'"
As permanent in-house engineers, they design and run adversarial simulations against our own environment, verify that the Blue Team's detections fire as intended, and act as the final security gate before any change reaches production. Nothing ships until it's been validated. The distinction matters: a control that has never been tested is a hope, not a defence — and the Purple Team's entire job is to remove that hope from the equation.
Four ways we prove the defences hold
Validation isn't a single audit; it's four continuous disciplines that together turn assumptions into evidence.
Attack simulation
Controlled, realistic adversary emulation against merlon's own systems to expose weaknesses before real attackers can. Scenarios are drawn from current threat behaviour, not a static checklist.
Control validation
Continuous verification that defensive barriers — detection rules, access controls, segmentation — actually work as designed. If a simulated attack should trigger an alert, they confirm it does.
Pre-production hardening
Every configuration and dependency is reviewed and hardened before it is promoted to a live environment. Insecure defaults and unnecessary surface area are removed, not documented.
Release gating
No update reaches production without passing the Purple Team's security validation — a hard gate, not a checkbox. A failed gate stops the release; it does not generate a waiver.
Adversary emulation, mapped to a framework
We use the MITRE ATT&CK framework as a methodology — a shared language of adversary techniques to structure and measure our testing. It is not a certification, and we don't present it as one. It simply keeps our coverage honest and comprehensive.
Map techniques
Threat scenarios are broken down into ATT&CK tactics and techniques, so testing spans the full attack lifecycle rather than a favourite few.
Emulate & observe
Each technique is emulated in a controlled way while the team watches whether the Blue Team's detections and controls respond as intended.
Feed back
Findings flow straight into detection rules and hardening standards, closing the loop with the Blue Team so the next simulation starts from a higher bar.
The gate every release must pass
Each change is simulated against known techniques, its controls are validated, the update is verified, and only then is it gated through to production.
A hard gate, not a checkbox
When release v2.14.0 reaches the gate, the Purple Team runs its simulation suite against the candidate build. Detections must fire, controls must hold, and hardening checks must pass. Any failure blocks promotion — the release goes back, it does not get waved through.
- Every gate result is recorded and auditable
- A failed check stops promotion automatically
- No manual override without a documented exception
release.promote env=production · v2.14.0
Assurance, measured
Testing the whole attack lifecycle
Adversaries don't stop at the front door. Our simulations exercise every stage of an intrusion, so a control that holds at initial access but fails at lateral movement is caught before an attacker would ever find it.
- Initial access
- Phishing payloads, exposed-service exploitation, and credential reuse are emulated to confirm perimeter detections and access controls respond.
- Execution & persistence
- Command execution, scheduled tasks, and account-creation techniques verify that endpoint telemetry and identity monitoring catch a foothold attempt.
- Privilege escalation & evasion
- Token manipulation and defense-impairment techniques test whether escalation is detected and whether evasion breaks our visibility.
- Lateral movement & exfiltration
- Cross-segment movement and simulated data egress confirm segmentation holds and egress anomalies are flagged before data leaves.
What we do with a finding
A discovered weakness is only useful if it drives change. Every Purple Team finding is tracked, prioritised, and fed into concrete remediation — with the loop closed by a re-test that proves the fix works.
From discovery to closed loop
Findings are logged with a technique reference, severity, and affected component. High-severity items block releases until remediated. Once fixed, the same simulation is re-run to confirm the gap is genuinely closed — not merely reported.
Log & classify
Each finding is recorded with an ATT&CK technique reference and an impact-based severity.
Remediate
Owners fix the root cause; detection rules and hardening standards are updated alongside.
Re-test to close
The original simulation is replayed to verify the control now holds before the finding is closed.
rule.update siem: token-reuse baseline
retest.pass simulation replay · detected
finding.close verified by purple-team
Two teams, one continuous loop
The Purple Team validates what the Blue Team defends — and the Blue Team monitors what the Purple Team hardens. Neither works in isolation.
Blue Team defends
Continuous 24/7 detection and telemetry across endpoints, logs, network, and identity. They are the ones who see the simulated attack — and whose detections the Purple Team is verifying.
Meet the Blue TeamPurple Team validates
Controlled attack simulation and release gating. Every finding flows back into the Blue Team's detection rules and hardening standards, raising the baseline with each cycle.
See the defense model