XZ Utils Backdoor: A Supply Chain Attack You Should Know About

Table of Contents

1. Module 1: The XZ Utils Supply Chain Backdoor
   • What Is XZ Utils and Why It Is Everywhere
   • Overview of the Vulnerability
   • The Social-Engineering Takeover of a Trusted Maintainer Role
   • Anatomy of the Backdoor: Obfuscated Build-Time Injection
   • How the Backdoor Hijacks SSH Authentication
   • Affected Versions and Distribution Exposure
   • Discovery: A Half-Second Anomaly That Unraveled the Plot
   • Business Impact and Who Is at Risk
   • Comparing XZ Utils to the SolarWinds Supply Chain Compromise
   • CVSS Scoring Breakdown
   • Proof-of-Concept and In-the-Wild Exploitation Status
   • Vulnerable vs. Exploitable: Assessing Real-World Risk
   • Indicators of Compromise and Detection Guidance
   • Immediate Mitigation and Remediation Steps
   • Supply Chain Security Lessons for Every Organization
2. Summary

Module 1: The XZ Utils Supply Chain Backdoor

What Is XZ Utils and Why It Is Everywhere

XZ Utils is a general-purpose compression suite conceptually similar to .zip or 7-Zip: it takes files and shrinks them so they can be stored or transferred more efficiently. What makes XZ Utils unusual is not the compression algorithm itself, but its reach. The liblzma library that ships as part of XZ Utils is imported as a base-build dependency by nearly every major Linux distribution — Debian, openSUSE, Fedora, Red Hat, Kali Linux, and many others — because so many other system components rely on it for compression services.

That ubiquity is exactly what turned a single poisoned open-source library into a near worst-case supply chain event. A vulnerability injected into a component this foundational does not stay contained to one application; it rides along inside the base operating system image of a huge share of the Linux ecosystem.

mindmap
  root((XZ Utils Supply Chain Incident))
    What XZ Utils Is
      General-purpose compression library
      Comparable to .zip / 7-Zip
      liblzma shared library
    Why It Matters
      Bundled into base OS builds
      Debian, openSUSE, Fedora, Red Hat, Kali
      Countless downstream dependents
    What Happened
      Malicious commits added over time
      Trusted co-maintainer identity
      Obfuscated build-time code injection
    Why It Is Different
      Open source, not closed source
      Caught unusually fast
      Required inbound connection, not outbound beacon

Overview of the Vulnerability

The XZ Utils backdoor is a supply chain vulnerability — more precisely, a supply-chain-injected vulnerability — planted directly inside the open source project itself. Over a series of commits into the upstream repository, a trusted contributor introduced code that, once compiled into a system, allowed a party holding a specific private key to log in over SSH and execute arbitrary commands without ever needing valid credentials. In short: fully unauthenticated remote code execution against any system that built and loaded the compromised library in the right configuration.

This is not a traditional memory-corruption bug like a buffer overflow. It is a deliberately engineered backdoor, hidden in plain sight inside a project that thousands of downstream packages trust implicitly.

The Social-Engineering Takeover of a Trusted Maintainer Role

The technical payload was only possible because of a long, patient social-engineering campaign against the project’s real maintainer. For roughly two years, a persona built up trust in the XZ Utils community, submitting legitimate patches and behaving as a normal, helpful contributor. Coordinated pressure — including complaints and impatience expressed by other accounts about the sole maintainer being slow to respond to patches and release cycles — nudged the original maintainer toward accepting additional help. Eventually, that persona was granted co-maintainer status and direct commit access to the repository.

This is the critical lesson embedded in the incident: the compromise did not require breaking any cryptography or exploiting any code defect. It required patiently earning the trust that legitimate open source contributors rely on every day, then abusing that trust once it was granted.

sequenceDiagram
    participant Persona as Malicious Contributor Persona
    participant Sockpuppets as Supporting Accounts
    participant Maintainer as Original Project Maintainer
    participant Repo as XZ Utils Upstream Repository

    Persona->>Repo: Submit legitimate, useful patches over time
    Persona->>Maintainer: Build reputation as a helpful contributor
    Sockpuppets->>Maintainer: Pressure for faster releases / more co-maintainers
    Sockpuppets->>Maintainer: Express frustration about slow patch review
    Maintainer->>Persona: Grant co-maintainer status and commit access
    Persona->>Repo: Introduce obfuscated build-time backdoor commits
    Repo->>Repo: Backdoor ships in 5.6.0 and 5.6.1 releases

Anatomy of the Backdoor: Obfuscated Build-Time Injection

The malicious logic was not written as obviously readable backdoor code inside a .c source file. Instead, it was smuggled in through the project’s build and test infrastructure — a technique specifically chosen to evade casual code review. The general mechanism, consistent with how this class of build-time supply chain backdoor operates, works as follows:

1. Specially crafted binary “test” files are added to the repository, disguised as ordinary test fixtures used to validate the compression library.
2. Build scripts (autoconf/m4 macros used during the configure and make process) are modified so that, during compilation, they extract and assemble a hidden malicious object file from those test fixtures.
3. That injected object file is linked into the final liblzma shared library, so the malicious code only exists in the built binary — never in a form that is easy to spot by reading the plain source tree.
4. The result is a liblzma.so that looks legitimate in source control history but contains an attacker-controlled code path once compiled and installed.

flowchart TD
    A["Malicious test fixture files\nadded to repository"] --> B["Obfuscated build (m4/configure)\nscripts modified"]
    B --> C["Build process extracts hidden\nobject code from test fixtures"]
    C --> D["Malicious object file linked\ninto liblzma.so at compile time"]
    D --> E["Compromised liblzma shared\nlibrary ships in distro packages"]
    E --> F["Library loaded by systemd /\nsshd on affected systems"]
    F --> G["Backdoor becomes live and\nreachable over SSH"]

    style A fill:#f66,color:#fff
    style B fill:#f66,color:#fff
    style C fill:#f66,color:#fff
    style D fill:#f96,color:#000
    style E fill:#fc6,color:#000
    style F fill:#fc6,color:#000
    style G fill:#f66,color:#fff

How the Backdoor Hijacks SSH Authentication

The reason this backdoor lands on SSH specifically comes down to a chain of library dependencies on certain Linux distributions. Some distributions patch OpenSSH’s sshd to link against libsystemd so that it can notify systemd of its startup status. libsystemd, in turn, depends on liblzma for compression support. That transitive dependency chain — sshd → libsystemd → liblzma — is what gives the compromised compression library a foothold inside the authentication path of the SSH daemon itself.

Once loaded into that process, the backdoor’s injected code intercepts a cryptographic function used during SSH authentication (public-key verification). If the connecting client presents a specific attacker-controlled key material, the backdoor code diverts execution to allow that party to run arbitrary commands — completely bypassing normal SSH authentication. If the check does not match that fixed criteria, execution proceeds normally, which is part of why the backdoor stayed hidden: to anyone SSHing in normally, nothing appeared wrong.

sequenceDiagram
    participant Attacker
    participant SSHD as sshd (SSH daemon)
    participant LibSystemd as libsystemd
    participant LibLZMA as liblzma (backdoored)
    participant Shell as System Shell

    Attacker->>SSHD: Initiate SSH connection with special key material
    SSHD->>LibSystemd: Load dependency for startup notification
    LibSystemd->>LibLZMA: Load dependency for compression support
    LibLZMA->>LibLZMA: Backdoored code intercepts auth-related function
    LibLZMA->>LibLZMA: Validate attacker's key material against hidden check
    alt Key matches backdoor criteria
        LibLZMA->>Shell: Execute attacker-supplied command
        Shell-->>Attacker: Command output / remote code execution
    else Key does not match
        LibLZMA->>SSHD: Continue normal authentication flow
        SSHD-->>Attacker: Standard SSH authentication result
    end

Illustrative representation of the injected authentication hook (not verbatim source code, provided to convey the mechanism):

/* Simplified conceptual illustration of an IFUNC-style resolver hook.
   This is NOT the actual malicious code, but represents the general
   technique publicly described for this class of backdoor: hooking a
   commonly-called cryptographic symbol via the dynamic linker's
   indirect function (IFUNC) resolution mechanism. */

__attribute__((ifunc("resolve_rsa_public_decrypt")))
int RSA_public_decrypt(int flen, const unsigned char *from,
                        unsigned char *to, RSA *rsa, int padding);

static void *resolve_rsa_public_decrypt(void) {
    /* At dynamic-link time, this resolver substitutes the address of
       a malicious wrapper function in place of the legitimate
       RSA_public_decrypt implementation used during SSH auth. */
    return backdoored_rsa_public_decrypt;
}

static int backdoored_rsa_public_decrypt(int flen, const unsigned char *from,
                                          unsigned char *to, RSA *rsa,
                                          int padding) {
    if (attacker_key_matches_backdoor_criteria(from, flen)) {
        execute_attacker_supplied_command(from, flen);
        return 0; /* short-circuit: bypass normal signature checks */
    }
    return real_rsa_public_decrypt(flen, from, to, rsa, padding);
}

Affected Versions and Distribution Exposure

The malicious code is confined to two specific XZ Utils releases: 5.6.0 and 5.6.1. Fortunately, at the time of discovery this had not yet propagated far downstream — it was primarily present in bleeding-edge, preview, or unstable distribution channels rather than widely deployed stable releases. A small number of distributions allow rolling back from the affected versions once identified.

Not every distribution that technically ships the vulnerable library version is actually exploitable. Some architectures package the affected release but do not wire it into the SSH authentication path the same way, so the backdoor’s live code path is never triggered even though the vulnerable code is technically present on disk.

flowchart TD
    A{Does the system have\nXZ Utils 5.6.0 or 5.6.1\ninstalled?} -->|No| Z[Not vulnerable]
    A -->|Yes| B{Does sshd on this\ndistro link against\nlibsystemd -> liblzma?}
    B -->|No| Y["Vulnerable library present,\nbut not exploitable via SSH"]
    B -->|Yes| C{Is the SSH service\nreachable from an\nuntrusted network?}
    C -->|No| X["Exploitable in theory,\nlower immediate risk\n(still needs remediation)"]
    C -->|Yes| W["High-risk: unauthenticated\nremote code execution\nis actively possible"]

    style W fill:#f66,color:#fff
    style X fill:#fc6,color:#000
    style Y fill:#fc6,color:#000
    style Z fill:#9f6,color:#000

Discovery: A Half-Second Anomaly That Unraveled the Plot

One of the most remarkable aspects of this incident is how it was found. A researcher noticed that SSH logins on an affected system were taking roughly half a second longer than expected, and that profiling tools were reporting unusually high CPU usage for what should have been a very lightweight, tightly controlled operation. That small, almost imperceptible timing anomaly — a handful of extra CPU cycles surfaced through performance profiling — was enough to trigger closer investigation, which eventually traced the anomaly back to the compromised liblzma library and exposed the entire scheme.

This discovery mechanism is a direct product of the open source model: an unusually large and technically engaged community of consumers was actively profiling and stress-testing these libraries for performance reasons, not specifically hunting for backdoors. That incidental scrutiny is what surfaced the issue far earlier than a closed-source equivalent likely would have been caught.

sequenceDiagram
    participant Researcher
    participant System as Affected Linux System
    participant Profiler as Performance/Memory Profiling Tools
    participant Community as Open Source Community
    participant Vendors as Distribution Maintainers

    Researcher->>System: Perform routine SSH login
    Researcher->>Researcher: Notice login is ~0.5s slower than expected
    Researcher->>Profiler: Investigate using CPU/memory profiling tools
    Profiler-->>Researcher: Report abnormal CPU cycles / errors
    Researcher->>Researcher: Trace anomaly back to liblzma
    Researcher->>Community: Disclose findings publicly
    Community->>Vendors: Rapidly confirm and corroborate the backdoor
    Vendors->>Vendors: Pull affected packages within ~48 hours

Business Impact and Who Is at Risk

What makes this incident unusual compared to many “intentional” supply chain backdoors is its target profile. Historically, deliberately planted backdoors of this kind have targeted server-oriented systems. This one instead rode along primarily in desktop-oriented Linux distributions — the operating systems most likely to be running on end-user workstations, not just back-end servers. That broadens the blast radius beyond typical server-focused incident response processes to include ordinary end-user machines.

For any organization running affected Linux systems, the practical business impact hinges on exposure:

• Any Linux server or endpoint with the vulnerable library and an internet-reachable SSH service is a direct target. Internet scanning platforms regularly find hundreds of thousands to millions of devices exposing SSH (or SSH-equivalent) ports.
• If the compromised update reached such a system, an unknown threat actor can log in and execute code on it — potentially compromising an entire environment without immediate detection.
• Even systems where SSH is only reachable internally (not exposed to the internet) still carry latent risk: an attacker who gains a foothold through an unrelated vulnerability could pivot to a system carrying this backdoor and use it for lateral movement.

flowchart LR
    subgraph Exposure["Exposure Scenarios"]
        direction TB
        A["Internet-facing Linux host\nwith affected library + open SSH"] --> R1["Highest risk:\ndirect unauthenticated RCE"]
        B["Internally-reachable host\nwith affected library"] --> R2["Moderate risk:\nlateral-movement pivot point"]
        C["Desktop workstation\nwith affected library, no SSH exposure"] --> R3["Lower immediate risk,\nstill requires remediation"]
    end

Comparing XZ Utils to the SolarWinds Supply Chain Compromise

The XZ Utils incident is frequently compared to the 2020 SolarWinds Orion compromise, since both are supply chain attacks that injected malicious code far upstream of the eventual victims. There are, however, meaningful differences:

flowchart TB
    subgraph SolarWinds["SolarWinds-Style Attack"]
        S1["Malicious code shipped\nin trusted software update"] --> S2["Backdoor beacons OUTBOUND\nover allowed HTTPS traffic"]
        S2 --> S3["Long dwell time before detection\n(~6-12 months)"]
    end
    subgraph XZUtils["XZ Utils-Style Attack"]
        X1["Malicious code shipped\nin trusted open source library"] --> X2["Backdoor requires attacker\nto connect INBOUND over SSH"]
        X2 --> X3["Caught within weeks via\nincidental performance profiling"]
    end

CVSS Scoring Breakdown

The vulnerability carries the maximum possible CVSS score: 10.0 out of 10. This reflects unauthenticated, low-complexity, no-user-interaction remote code execution with high impact to confidentiality, integrity, and availability — the ceiling of the scoring model.

One important nuance raised during risk discussions: a 10.0 score is sometimes discounted in practice when the affected component is unlikely to be internet-exposed. That discount does not comfortably apply here — a very large number of Linux systems that could carry this update also expose an SSH-equivalent service to the internet, so the theoretical maximum severity and the practical real-world severity remain closely aligned.

flowchart LR
    A["Attack Vector: Network"] --> F["Base Score\nBuild-Up"]
    B["Attack Complexity: Low"] --> F
    C["Privileges Required: None"] --> F
    D["User Interaction: None"] --> F
    E["Impact: High / High / High"] --> F
    F --> G["CVSS 10.0 — Critical"]

    style G fill:#f00,color:#fff

Proof-of-Concept and In-the-Wild Exploitation Status

Rather than a conventional “exploit,” proof-of-concept demonstrations for this vulnerability center on possession of the attacker’s private key material rather than a memory-corruption trigger like a buffer overflow payload. Because the backdoor is functionally just a hidden authentication bypass tied to a specific key, “using” it looks like a completely normal SSH login — the attacker simply connects the way they always would, using the key that the backdoor was built to recognize.

Security researchers have published honeypots designed to detect connection attempts using the known private key associated with this backdoor, which has provided some visibility into exploitation attempts in the wild. However, the identity of the original threat actor behind the backdoor remains unknown.

Vulnerable vs. Exploitable: Assessing Real-World Risk

A critical distinction for risk triage is the difference between a system being vulnerable (it contains the affected library version) and a system being exploitable (the backdoor’s live code path can actually be triggered). Some Linux flavors package the vulnerable version of XZ Utils but, due to how their build wires dependencies together, never actually load the malicious path into the SSH authentication flow — meaning they still need patching, but they are not immediately exploitable the same way.

The practical exploitability checklist looks like this:

1. Library present — the system has installed an OS update or package containing XZ Utils 5.6.0 or 5.6.1.
2. Dependency wiring present — the distribution’s patched sshd links against libsystemd, which in turn loads liblzma, activating the backdoor’s code path (distributions like Arch Linux ship the vulnerable library without this wiring, and are not exploitable through SSH as a result).
3. Network reachability — the SSH-equivalent service is reachable from an untrusted network. Note that the service will not always be on the default port 22; administrators frequently move SSH to a non-standard port, so any exposed port running the SSH protocol should be treated as in-scope, not just port 22.

flowchart TD
    Start([Assess a given host]) --> Q1{XZ Utils 5.6.0\nor 5.6.1 installed?}
    Q1 -->|No| NotVuln([Not vulnerable])
    Q1 -->|Yes| Q2{sshd linked via\nlibsystemd -> liblzma?}
    Q2 -->|No| VulnOnly([Vulnerable but not\nexploitable via SSH\nstill needs patching])
    Q2 -->|Yes| Q3{SSH service reachable\nfrom untrusted network\n_any_ port, not just 22}
    Q3 -->|No| Internal([Exploitable internally\nlateral-movement risk])
    Q3 -->|Yes| Critical([Actively exploitable\nunauthenticated RCE])

    style Critical fill:#f66,color:#fff
    style Internal fill:#fc6,color:#000
    style VulnOnly fill:#fc6,color:#000
    style NotVuln fill:#9f6,color:#000

Indicators of Compromise and Detection Guidance

Because the backdoor’s activation looks like a normal SSH login on the surface, detection needs to rely on a mix of asset inventory, connection auditing, and behavioral analysis rather than a single simple signature.

flowchart TD
    A([Start Detection Workflow]) --> B{Scan fleet for\nXZ Utils 5.6.0/5.6.1?}
    B -->|Found| C[Flag host as vulnerable]
    C --> D{Review inbound SSH\nconnections to host}
    D --> E{Commands executed\nunder SSH daemon identity\ninstead of user identity?}
    E -->|Yes| F([High-confidence IOC:\ntreat as compromised])
    E -->|No| G{Connections outside\nnormal working hours?}
    G -->|Yes| H([Investigate further:\nbehavioral anomaly])
    G -->|No| I([Continue monitoring])
    B -->|Not Found| J([Host not vulnerable\nby this vector])

    style F fill:#f66,color:#fff
    style H fill:#fc6,color:#000

# Illustrative, representative commands for triaging exposure —
# adjust package manager syntax to your actual distribution.

# 1) Check installed XZ Utils / liblzma version
xz --version
dpkg -l | grep -i xz-utils      # Debian/Ubuntu-family
rpm -qa | grep -i xz            # Red Hat/Fedora-family

# 2) Check whether sshd is linked against the affected library chain
ldd "$(command -v sshd)" | grep -E "liblzma|libsystemd"

# 3) Audit external SSH sessions for anomalous parent/child process identity
#    (legitimate sessions run under the connecting user; a mismatch where
#    commands run as the sshd/system identity is a strong IOC)
ps -eo pid,ppid,user,cmd | grep -i sshd

# 4) Review authentication logs for connections outside normal hours
journalctl -u sshd --since "-7 days" | grep -i "Accepted"

Immediate Mitigation and Remediation Steps

Because exploitation ultimately requires an attacker to connect inbound, mitigation follows a familiar defense-in-depth pattern for internet-reachable services: reduce exposure first, then add detection, then patch.

1. Restrict exposure. Do not expose SSH (or whatever port the SSH service runs on) to untrusted networks unless absolutely necessary. This is the single highest-value mitigation.
2. Monitor and detect. Where external SSH exposure cannot be eliminated, actively monitor those connections for the indicators of compromise described above — process identity mismatches, connections outside normal hours, and known-key matches.
3. Roll back or patch. Distribution vendors published rollback guidance for every affected release almost immediately after disclosure. Identify any system carrying XZ Utils 5.6.0 or 5.6.1 and roll back to an unaffected version (or apply the vendor-provided patched build) as soon as possible.

flowchart TD
    A([Vulnerable/exploitable host identified]) --> B{Can SSH exposure\nbe restricted?}
    B -->|Yes| C[Remove/restrict external\nSSH access immediately]
    B -->|No| D[Add enhanced monitoring:\nprocess identity, timing,\nknown-key detection]
    C --> E[Roll back or patch\nto unaffected XZ Utils version]
    D --> E
    E --> F([Confirm remediation and\ncontinue monitoring])

Supply Chain Security Lessons for Every Organization

This incident should prompt every organization to step back and re-examine how it thinks about its software supply chain — because in this case, the “supply chain” in question was the operating system itself. A few key realities emerge:

• You cannot fully audit everything you run. Even large, well-resourced enterprise Linux distributions incorporate thousands of third-party libraries; realistically, no internal team is independently reviewing the source code of every dependency, open or closed source.
• Supply chain risk is not eliminated by policy documents alone. A risk register entry saying “don’t use vulnerable libraries” does nothing to stop a trusted upstream maintainer relationship from being abused — by the time a compromise like this is discovered, it may already be present across thousands of systems.
• Assume eventual compromise, and build for it. Just as with every other category of security risk, part of a mature supply chain security program has to plan for the reality that a trusted component will, at some point, turn out to be malicious — and needs an elevated risk posture and response plan ready in advance.
• Prioritize and protect your most important assets first. No organization can audit every dependency, so risk assessment should focus resources on the systems and data that matter most, with layered protections calibrated to that priority.
• Operationalize risk management. Risk assessments need to be tightly coupled to the operational teams who can actually act on them — assigning risk on paper does nothing if it never reaches the people who configure firewalls, monitoring, and access controls.
• Rehearse your response. Tabletop exercises for “a trusted software component turns out to be compromised” scenarios help ensure that when (not if) this happens again, the organization can respond quickly rather than improvising under pressure.

mindmap
  root((Supply Chain Security Lessons))
    Cannot Audit Everything
      Thousands of third-party libraries
      Even enterprise distros affected
      Trust is inherently distributed
    Policy Is Not Enough
      Paper risk registers don't stop abuse
      Compromise can precede detection by months
    Assume Compromise
      Elevated risk posture by default
      Plan mitigation, not just prevention
    Prioritize Assets
      Focus scarce resources on critical systems
      Layered protection by importance
    Operationalize Risk
      Connect risk teams to operational teams
      Turn assessments into real controls
    Rehearse Response
      Tabletop exercises
      Practice before it happens for real

Summary

The XZ Utils backdoor (publicly tracked as CVE-2024-3094) is one of the most consequential open source supply chain incidents on record — not because of how widely it spread, but because of how close it came to spreading much further before an alert engineer noticed a half-second delay during an SSH login. A patient, multi-year social-engineering campaign earned a malicious actor legitimate co-maintainer trust over a widely-depended-upon compression library. That trust was used to smuggle an obfuscated, build-time-injected backdoor into liblzma versions 5.6.0 and 5.6.1, which — on distributions where sshd transitively links against the library through libsystemd — allowed a holder of a specific private key to bypass SSH authentication entirely and execute arbitrary commands.

The incident carries a maximum CVSS score of 10.0, reflecting unauthenticated, low-complexity remote code execution with full impact to confidentiality, integrity, and availability. It was contained largely to bleeding-edge and rolling-release distribution channels, and rapid, community-driven discovery meant the malicious releases were pulled within roughly 48 hours of disclosure — a sharp contrast to incidents like SolarWinds, where detection took the better part of a year. That speed of discovery was a direct benefit of the open source model: broad, technically engaged scrutiny from the community, driven by ordinary performance profiling rather than a dedicated backdoor hunt.

Supply Chain Security Checklist

• Inventory all systems for XZ Utils 5.6.0 and 5.6.1 (or any component depending on a known-affected build).
• Confirm whether sshd on each affected system links against libsystemd → liblzma, to distinguish “vulnerable” from “actively exploitable.”
• Restrict SSH (and any SSH-equivalent service, regardless of port) from untrusted or internet-facing exposure wherever possible.
• Monitor SSH sessions for process-identity mismatches (commands running as the SSH daemon rather than the authenticated user).
• Watch for connections outside normal administrative hours and cross-reference with known-key/honeypot-derived indicators.
• Roll back or patch any system carrying the affected XZ Utils release immediately, following vendor-provided guidance.
• Treat internally-reachable instances as lateral-movement risks, not just internet-facing ones.
• Reassess how your organization vets and grants trust to upstream open source maintainers and dependencies.
• Maintain a software bill of materials (SBOM) program, while accepting that an SBOM alone cannot prevent this class of attack — pair it with an incident response plan assuming eventual compromise.
• Tightly couple risk assessment output with the operational teams responsible for firewalls, monitoring, and access controls.
• Run tabletop exercises simulating a trusted open source dependency turning out to be compromised.
• Prioritize protection and monitoring around your organization’s most critical assets, since full dependency-by-dependency auditing is not realistically achievable.

Search Terms

xz · utils · backdoor · supply · chain · attack · know · vulnerability · briefings · networking · systems · security · compromise · risk