15.4 Adversarial Simulation: Thinking Like an Attacker¶
The attackers who compromised SolarWinds didn't target random systems—they specifically chose a software vendor whose products were deployed in high-value government and enterprise networks. They understood that one successful compromise would cascade to 18,000 downstream organizations.1 This is adversarial thinking: understanding how attackers evaluate targets, choose attack paths, and maximize return on their investment. Defenders who think like attackers identify vulnerabilities before exploitation and prioritize defenses where they matter most.
This section develops the adversarial mindset for supply chain security, providing techniques for analyzing attack paths, identifying weak links, and translating attacker insights into effective defenses.
Developing an Adversarial Mindset¶
Adversarial thinking means systematically considering how attackers would target your organization, using their goals, constraints, and economics to predict their behavior.
Mindset Principles:
1. Attackers Are Rational Actors:
Most attackers (criminal and nation-state alike) make rational decisions about where to invest effort:
| Factor | Attacker Consideration |
|---|---|
| Target value | What can I gain from compromising this? |
| Attack difficulty | How hard is this to exploit? |
| Detection risk | How likely am I to get caught? |
| Alternatives | Is there an easier path to the same goal? |
2. Defenders Think in Lists; Attackers Think in Graphs:
Defenders often approach security as checklists: patch these systems, configure these controls, monitor these logs. Attackers think in connected paths: "If I compromise A, I can reach B, which gives me access to C."
Defender View: Attacker View:
☐ Patch Jenkins Developer laptop
☐ Rotate secrets ↓
☐ Enable 2FA GitHub access
☐ Review logs ↓
Pipeline secrets
↓
Production deployment
↓
Customer data
3. The Attacker Only Needs One Path:
Defenders must protect everything; attackers need only find one weakness. This asymmetry demands prioritization—focus on paths with highest impact and likelihood.
4. Attackers Adapt:
When you close one path, sophisticated attackers find another. Static defenses eventually fail; continuous adversarial assessment is required.
When organizations analyze their build systems from an attacker's perspective, they often discover that security controls are optimized for a different threat model—strong perimeter security but implicit trust for everything inside. This is exactly what supply chain attackers exploit.
Attack Path Analysis¶
Attack path analysis maps how an attacker could progress from initial access to their objective through your systems.
Mapping Your Supply Chain Attack Surface:
Start by identifying components an attacker might target:
┌─────────────────────────────────────────────────────────────┐
│ ATTACK SURFACE MAP │
├─────────────────────────────────────────────────────────────┤
│ │
│ PEOPLE SYSTEMS PROCESSES │
│ ├─ Developers ├─ Source repos ├─ Code review │
│ ├─ Maintainers ├─ CI/CD ├─ Dependency mgmt │
│ ├─ DevOps ├─ Artifact repos ├─ Release process │
│ └─ Third parties ├─ Build runners └─ Access approval │
│ └─ Signing infra │
│ │
│ DEPENDENCIES INFRASTRUCTURE CREDENTIALS │
│ ├─ Direct deps ├─ Cloud accounts ├─ API tokens │
│ ├─ Transitive deps ├─ Networks ├─ SSH keys │
│ ├─ Dev tools └─ DNS ├─ Signing keys │
│ └─ Build tools └─ Registry creds │
│ │
└─────────────────────────────────────────────────────────────┘
Path Enumeration:
For each attacker goal, enumerate paths to reach it:
# Attack Path Analysis: Backdoor Production Code
### Goal: Insert persistent backdoor into deployed application
### Path 1: Compromise Developer
- Phish developer credentials
- Access source repository
- Commit malicious code
- Pass code review (social engineering or compromised reviewer)
- Code deployed through normal pipeline
### Path 2: Compromise CI/CD
- Exploit Jenkins vulnerability
- Modify build script to inject payload
- Payload included in build artifacts
- Artifacts deployed to production
### Path 3: Compromise Dependency
- Identify commonly used internal package
- Compromise maintainer or registry
- Push malicious version
- Dependency pulled during build
- Malicious code deployed
### Path 4: Compromise Artifact Repository
- Gain access to Artifactory/Nexus
- Replace legitimate artifact with backdoored version
- Backdoored artifact deployed to production
### Path Assessment
| Path | Difficulty | Detection Risk | Impact |
|------|------------|----------------|--------|
| 1 | Medium | Medium | High |
| 2 | Medium | Low | High |
| 3 | Low | Low | High |
| 4 | High | Medium | High |
Attack Trees:
Structure paths as attack trees for systematic analysis:
[Backdoor Production]
│
┌───────────────┼───────────────┐
│ │ │
[Compromise [Compromise [Compromise
Source] Build] Distribution]
│ │ │
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│ │ │ │ │ │
[Phish Dev] [Steal [Exploit [Modify [Replace [Poison
Keys] Jenkins] Config] Artifact] Mirror]
Identifying the Weakest Links¶
Not all attack surface is equal. Focus on paths that are easiest to exploit with highest impact.
Weak Link Indicators:
| Indicator | Why It's Weak |
|---|---|
| Single point of failure | Compromise one thing, affect everything |
| Implicit trust | No verification, assumed secure |
| Manual processes | Human error, social engineering |
| Legacy systems | Outdated security, limited visibility |
| Third-party dependencies | Outside your security controls |
| Shared credentials | Compromise one, access many |
Weak Link Assessment Technique:
For each component in your supply chain, rate:
## Component Risk Assessment
### Component: Internal NPM Registry
| Factor | Rating (1-5) | Notes |
|--------|--------------|-------|
| Access controls | 2 | All developers have publish access |
| Monitoring | 1 | No alerting on unusual activity |
| Integrity verification | 1 | No signing or checksums |
| Update frequency | 4 | Regularly maintained |
| Expertise | 3 | Moderate team knowledge |
| Recovery capability | 2 | No backup of packages |
**Risk Score**: 13/30 (High Risk)
**Weakest Aspects**:
- Any developer can publish (single compromised dev = compromised registry)
- No detection of malicious publishes
- No integrity verification downstream
**Attacker Appeal**: HIGH - Easy target, high impact
Common Weak Links in Supply Chains:
| Area | Common Weaknesses |
|---|---|
| Developer access | Broad permissions, weak MFA adoption |
| CI/CD secrets | Over-permissioned, long-lived tokens |
| Dependency management | No vetting, auto-update without review |
| Build runners | Shared environments, insufficient isolation |
| Artifact storage | Mutable artifacts, no integrity checks |
| Release process | Single approver, no separation of duties |
Attacker Economics and ROI Thinking¶
Understanding attacker economics helps predict which targets they'll choose.
Attacker Investment Factors:
| Investment | Considerations |
|---|---|
| Research time | How long to understand target? |
| Exploit development | Is there existing tooling or custom work needed? |
| Infrastructure | Domains, servers, C2 infrastructure |
| Operational security | Avoiding detection and attribution |
| Persistence maintenance | Keeping access over time |
Attacker Return Factors:
| Return | Value |
|---|---|
| Direct financial | Cryptocurrency theft, fraud |
| Data value | PII, credentials, intellectual property |
| Access value | Pivot to higher-value targets |
| Strategic value | Espionage, disruption |
| Scale | One compromise affecting many victims |
ROI Analysis from Attacker Perspective:
## Target: Your Organization's NPM Registry
### Attacker Investment
- Research: 2 days (understand structure)
- Exploit: 1 day (credential phishing)
- Infrastructure: Minimal (existing)
- OpSec: Low (hard to attribute)
**Total: ~3 days effort**
### Attacker Return
- Access to all internal packages
- Indirect access to all downstream applications
- Potential access to customer deployments
- Persistence through legitimate-looking updates
**Scale: 100+ applications, 50+ customers**
### ROI Assessment
- Investment: Low
- Return: Very High
- Detection Risk: Low
**Verdict: HIGHLY ATTRACTIVE TARGET**
Implications for Defense:
Prioritize defenses for high-ROI attacker targets: - Reduce attacker return (limit blast radius, segment access) - Increase attacker investment (add security controls, require sophistication) - Increase detection risk (monitoring, anomaly detection)
Staying Current with Attacker Techniques¶
Supply chain attacks evolve. Defenders must track emerging techniques.
Threat Intelligence Sources:
| Source | Value | Examples |
|---|---|---|
| Vendor advisories | Platform-specific threats | GitHub Security Blog, npm advisories |
| Security research | Novel techniques | Academic papers, conference talks |
| Incident reports | Real-world attacks | Post-mortems, case studies |
| Threat feeds | Active threats | CISA advisories, sector ISACs |
| Community | Emerging patterns | Twitter/X, security Slack/Discord |
Recommended Follows:
- GitHub Security Lab: Research on supply chain attacks
- Snyk Security Research: Dependency vulnerability research
- Socket.dev Blog: Package security analysis
- CISA Advisories: Government threat intelligence
- Hacker News/Reddit Security: Community discussion
Technique Tracking Framework:
## Supply Chain Attack Technique Tracking
### New Technique: [Name]
**Date Observed**: [Date]
**Source**: [How we learned about it]
### Description
[What the technique does]
### Attack Path
[How it fits into attack chains]
### Our Exposure
- [ ] Applicable to our environment?
- [ ] Current controls effective?
- [ ] Detection capability exists?
### Actions
- [ ] Update threat model
- [ ] Assess defenses
- [ ] Update detection rules
- [ ] Brief relevant teams
Tracking Cadence:
| Activity | Frequency |
|---|---|
| Review threat feeds | Weekly |
| Update technique library | Monthly |
| Reassess attack paths | Quarterly |
| Major threat model update | Annually |
Translating Adversarial Insights into Defenses¶
Adversarial analysis is only valuable if it improves defenses.
Defense Prioritization Framework:
## Defense Prioritization from Attack Analysis
### Attack Path: Compromised Developer → Malicious Commit
| Control | Blocks Path? | Implementation Cost | Priority |
|---------|--------------|---------------------|----------|
| Mandatory MFA | Partially | Low | P1 |
| Required code review | Partially | Medium | P1 |
| Signed commits | Partially | Medium | P2 |
| Branch protection | Partially | Low | P1 |
| Behavioral monitoring | Detection only | High | P2 |
### Recommendation
No single control blocks this path completely. Implement layered defenses:
1. MFA + branch protection (immediate, low cost)
2. Mandatory code review (near-term)
3. Commit signing (medium-term)
4. Behavioral monitoring (long-term)
Control Effectiveness Assessment:
For each attack path, evaluate controls:
| Control Type | Questions |
|---|---|
| Preventive | Does this stop the attack? Completely or partially? |
| Detective | Does this detect the attack? How quickly? |
| Responsive | Can we contain/recover if attack succeeds? |
Gap Analysis:
## Control Gap Analysis
### Attack Path: CI/CD Compromise
| Attack Step | Existing Controls | Gaps |
|-------------|------------------|------|
| Initial access | VPN, SSO | No anomaly detection |
| Privilege escalation | RBAC | Over-permissioned roles |
| Lateral movement | Network segmentation | Build runners share network |
| Payload injection | None | No build integrity verification |
| Persistence | Audit logs | Logs not monitored |
| Exfiltration | Egress filtering | Allow-list too broad |
### Critical Gaps
1. No build integrity verification (allows undetected modification)
2. Over-permissioned CI/CD roles (allows escalation)
3. Logs not monitored (allows persistence)
Continuous Adversarial Assessment¶
One-time analysis becomes stale. Build continuous adversarial assessment into operations.
Continuous Assessment Activities:
| Activity | Frequency | Output |
|---|---|---|
| Attack surface review | Monthly | Updated surface map |
| Path analysis refresh | Quarterly | Revised attack paths |
| Control effectiveness | Quarterly | Gap report |
| Threat technique update | Monthly | Updated threat library |
| Red team exercise | Semi-annually | Validated findings |
Integration with Security Operations:
- Include attack path context in vulnerability prioritization
- Brief SOC on relevant attack techniques
- Update detection rules as techniques evolve
- Share adversarial insights with engineering teams
Maturity Model:
| Level | Characteristics |
|---|---|
| Initial | Ad-hoc adversarial thinking, no formal process |
| Developing | Periodic attack path analysis, documented threats |
| Defined | Regular adversarial assessment, integrated with defense |
| Managed | Continuous analysis, metrics-driven improvement |
| Optimizing | Predictive adversarial modeling, proactive defense |
Recommendations¶
For Security Practitioners:
-
Map your attack paths. Document how an attacker could reach your crown jewels through your supply chain. Prioritize paths by attacker ROI.
-
Think in graphs, not lists. Connect components into attack chains. Identify where one compromise enables another.
-
Track attacker evolution. Supply chain attacks are advancing rapidly. Dedicate time to following emerging techniques.
For Security Architects:
-
Design for adversarial conditions. Assume components will be compromised. Build in verification, segmentation, and detection.
-
Calculate attacker ROI. Evaluate which targets offer attackers the best return. Those need strongest defenses.
-
Layer defenses on high-value paths. No single control is sufficient. Require attackers to defeat multiple controls on any path to critical assets.
For Organizations:
-
Institutionalize adversarial thinking. Make attack path analysis part of security review processes, not a special exercise.
-
Invest in red team capability. Internal or external red teams validate adversarial analysis with real attacks.
-
Close the loop. Adversarial insights must translate into defense improvements. Track from finding to remediation.
Thinking like an attacker transforms security from reactive to proactive. Instead of waiting for vulnerabilities to be discovered or attacks to succeed, defenders who understand adversarial economics and attack paths can anticipate threats and prepare defenses in advance. This mindset—systematically asking "how would I attack this?"—is the foundation of effective supply chain security.
-
SolarWinds SEC Form 8-K filing, December 2020; Microsoft Security Blog, "Analyzing Solorigate," December 2020. ↩