Intermediate

Security Hot Takes: Buzzwords and Predictions

The overarching takeaway is that separating genuine technical substance from marketing language requires asking, for any buzzword: what specific capability gap does this actually close, i...

Table of Contents

Module 1: 2023 Security Buzzwords and Predictions

Discussion Format

Two security practitioners independently wrote down the buzzwords and predictions they expected to dominate the cybersecurity industry through 2023, then compared notes one at a time to see where their picks matched. The exercise surfaces both genuine industry-wide consensus (where both practitioners landed on the same term independently) and areas of professional disagreement about which trends are substance versus marketing noise.

For each term discussed below, the analysis separates:

  • What the buzzword/prediction actually means technically.
  • Why it is being marketed the way it is (the hype angle).
  • Whether the practitioners agreed independently (“matched”) or only one of them raised it.
  • Their shared or differing outlook for the rest of the year.

The table below summarizes every topic covered, in the order it came up:

#Buzzword / PredictionIndependent Match?2023 Outlook (Consensus)
1AI / Machine Learning / ChatGPTYesWill dominate industry conversation all year
2Bills of Materials (SBOM/FBOM/HBOM/BBOM)No (one practitioner only)Agreed it will stay prevalent, largely due to government mandates
3Ransomware-as-a-Service / Malware-as-a-ServiceNoAgreed the underlying commoditization trend will continue
4OT Ransomware (PLC-level encryption)N/A (single prediction)Agreed this is a credible, escalating risk for 2023
5Software Supply Chain AttacksNoAgreed it will keep growing as an initial access vector
6Cloud Native SecurityNoAgreed it is a real gap, but tooling maturity is still years out
7EDR / XDR / MXDR (“alphabet soup”)YesAgreed vendors will keep adding acronyms, with diminishing differentiation
8Automated Red TeamingN/A (single prediction)Agreed vendors will keep selling it, but it won’t replace real red team engagements
mindmap
  root((2023 Security<br/>Buzzwords &amp; Predictions))
    AI / ML / ChatGPT
      Generative AI hype
      Security use cases still forming
    Bills of Materials
      SBOM
      FBOM
      HBOM
      BBOM
    As-a-Service Crime
      Ransomware-as-a-Service
      Malware-as-a-Service
    OT Ransomware
      PLC encryption payloads
      Critical infrastructure targeting
    Supply Chain Attacks
      Software dependency compromise
      New initial access vector
    Cloud Native Security
      Immature monitoring/detection tooling
      New umbrella marketing term
    Alphabet Soup Detection
      EDR
      XDR
      MXDR
    Automated Red Teaming
      Vulnerability scanning
      Automated adversary emulation
      Manual red team operations

The following quadrant chart is an illustrative visualization of the practitioners’ own sentiment during the discussion — plotting each buzzword by how much marketing hype it was getting on the security conference circuit versus how much genuine, deliverable security value the practitioners felt it currently provided. It is not a formal industry survey, just a synthesis of the opinions expressed in the conversation.

quadrantChart
    title Hype vs. Practical Security Value (2023 sentiment)
    x-axis Low Hype --> High Hype
    y-axis Low Current Value --> High Current Value
    quadrant-1 Justified Attention
    quadrant-2 Underrated
    quadrant-3 Fading Noise
    quadrant-4 Overhyped
    AI / ChatGPT: [0.92, 0.5]
    Bills of Materials: [0.55, 0.72]
    RaaS / MaaS: [0.48, 0.5]
    OT Ransomware: [0.22, 0.85]
    Supply Chain Attacks: [0.5, 0.8]
    Cloud Native Security: [0.85, 0.32]
    EDR/XDR/MXDR: [0.88, 0.3]
    Automated Red Team: [0.6, 0.25]

AI, Machine Learning, and ChatGPT

The first and, by consensus, the single most unavoidable topic of the year: artificial intelligence, machine learning, and — more specifically — large language model tools like ChatGPT. Both practitioners wrote this down independently without any prompting, calling it something that has been “shoved down our throats” across the industry.

The technical distinction worth preserving here is that “AI” as an industry buzzword conflates several very different things:

  • Machine learning (ML) — statistical models trained on data to classify, predict, or detect anomalies (already long-embedded in security tooling such as malware classifiers, UEBA, and spam filters).
  • Generative AI / large language models (LLMs) — models like ChatGPT that generate novel text, code, or other content based on a prompt, as opposed to classifying existing data.

The prediction is not narrowly about a specific technical capability, but about the sheer volume of vendor and media attention the category was expected to receive throughout 2023, regardless of whether the underlying security use cases were mature.

Bills of Materials: SBOM, FBOM, HBOM, and BBOM

Only one practitioner had this on their list, but both agreed strongly that “bill of materials” concepts — in whatever specific flavor — would remain a fixture on vendor conference floors (RSA, Black Hat) for the rest of the year.

The umbrella term covers an inventory of a system’s constituent parts so that organizations can track and respond to newly disclosed vulnerabilities in dependencies they may not have direct visibility into:

AcronymFull NameWhat It Inventories
SBOMSoftware Bill of MaterialsSoftware components/libraries/dependencies used to build an application
FBOMFirmware Bill of MaterialsFirmware components embedded in a device
HBOMHardware Bill of MaterialsPhysical hardware components and sub-components
BBOM(Behavioral) Bill of MaterialsRuntime/behavioral characteristics of a system, as opposed to static composition

A representative CycloneDX-format SBOM fragment illustrates what this actually looks like in practice (illustrative example, not from a specific vendor deliverable):

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "log4j-core",
      "version": "2.17.1",
      "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1",
      "licenses": [{ "license": { "id": "Apache-2.0" } }]
    },
    {
      "type": "library",
      "name": "openssl",
      "version": "3.0.7",
      "purl": "pkg:generic/openssl@3.0.7"
    }
  ]
}

The key driver behind this prediction is regulatory, not purely technical: the practitioners specifically called out that the US government has begun dictating requirements around SBOMs for software sold to federal agencies. That kind of top-down mandate is exactly the sort of pressure that keeps a compliance-adjacent buzzword alive well past its initial hype cycle, because organizations are compelled to adopt it regardless of whether the tooling ecosystem is fully mature.

Ransomware-as-a-Service and Malware-as-a-Service

This entry did not match between the two practitioners, but sparked one of the more pointed discussions of the conversation: the “as-a-service” framing being applied to criminal ransomware and malware operations.

Technically, Ransomware-as-a-Service (RaaS) and Malware-as-a-Service (MaaS) describe a division of labor within the criminal ecosystem, mirroring legitimate “as-a-service” business models (Software-as-a-Service, Infrastructure-as-a-Service, Cloud-as-a-Service):

RoleFunction
Ransomware/Malware OperatorDevelops and maintains the malicious code, infrastructure, and “customer support” for affiliates
AffiliateUses the operator’s tooling/infrastructure to actually breach a target and deploy the payload
Initial Access Broker (IAB)Sells already-compromised access into target networks to affiliates or operators

The practitioners pointed out the language itself has a normalizing effect: threat actors describing their offering as “Ransomware-as-a-Service” gives the criminal operation an air of legitimacy — as if they are simply providing infrastructure and a “risk matrix,” with no direct responsibility for what affiliates ultimately do with it. One practitioner wryly summarized the operator’s implicit defense as: “we just wrote the ransomware, it’s not our fault” if an affiliate uses it to cause a breach — an attempt to create legal and reputational distance similar to how attribution disputes work at the nation-state level.

Despite disagreeing on whether “as-a-service” itself would be the exact dominant buzzword, both agreed that the underlying trend — continued commoditization of criminal capability, where ransomware evolves and gets sold/rented across different threat actors and targets — would persist through 2023.

flowchart LR
    A[Ransomware/Malware Operator<br/>develops code + infrastructure] -->|leases access to| B[Affiliate]
    C[Initial Access Broker] -->|sells compromised access| B
    B -->|deploys payload against| D[Victim Organization]
    D -->|ransom payment| A
    D -->|ransom payment share| B

OT Ransomware: The Next Critical Infrastructure Threat

This was framed less as a buzzword and more as a specific, forward-looking prediction: that 2023 would see the onset of significant operational technology (OT) ransomware events — not the Colonial Pipeline pattern, where IT systems were encrypted and OT was shut down only as a precaution, but ransomware that directly encrypts programmable logic controllers (PLCs) themselves, halting the physical manufacturing or critical infrastructure process until a ransom is paid.

The distinction matters technically:

  • IT-triggered OT shutdown (e.g., Colonial Pipeline 2021): ransomware encrypts business IT systems (billing, logistics); the OT/ICS environment is shut down out of caution because operators can no longer verify billing/safety systems, even though the OT systems themselves were not directly compromised.
  • Direct OT/PLC-level ransomware: the ransomware payload targets and encrypts the PLC or its logic directly, so the actual physical process (manufacturing line, pipeline valve control, power distribution) stops functioning until decrypted.

The prediction was grounded in real, already-observed precedent rather than speculation:

  • Stuxnet (the widely cited original critical-infrastructure cyber-physical attack).
  • Pipedream (also publicly tracked as INCONTROLLER/CHERNOVITE) — modular ICS-specific attack framework discovered in 2022, purpose-built to interact with PLCs and human-machine interface (HMI) devices, effectively a framework capable of running as a control-theory attack tool against OT.
  • A separate 2022 incident in which a criminal group demonstrated the ability to encrypt a PLC directly as part of a ransomware payload.
  • Public threats from top-tier ransomware groups against EU transportation and critical infrastructure sectors.
flowchart TD
    A[Stuxnet<br/>proof that cyber can<br/>cause physical damage] --> B[Pipedream / INCONTROLLER<br/>2022: modular ICS attack<br/>framework targeting PLCs/HMIs]
    B --> C[2022: criminal group demonstrates<br/>direct PLC encryption as ransomware payload]
    C --> D{"2023 Prediction:<br/>Direct OT/PLC ransomware<br/>becomes mainstream"}
    D --> E[Manufacturing lines halted<br/>until ransom paid]
    D --> F[Critical infrastructure processes<br/>(power, water, transport) at risk]

Both practitioners agreed this was a credible and serious escalation to watch for, while also noting the uncomfortable irony that being “right” about the prediction would mean something genuinely damaging had occurred.

Software Supply Chain Attacks as a New Initial Access Vector

Historically, phishing has been the most common initial access technique used by attackers, and security awareness training programs have been built almost entirely around defending against it. The prediction here is that software supply chain attacks — compromising a piece of trusted third-party software or a dependency, rather than directly phishing a user — are becoming a significant new initial access vector that organizations must now defend against and train for.

Part of what is driving this shift is measurable success against phishing itself:

  • Microsoft disabled auto-enabled macros in files downloaded from the internet by default, removing a very commonly abused initial access vector (malicious Office macro documents).
  • General user security awareness around phishing has improved as training programs have matured and become mainstream.

As a result, attackers are increasingly pivoting toward compromising the software supply chain itself — inserting malicious code into a trusted dependency, build pipeline, or update mechanism so that it is distributed to victims through software they already trust and have already installed, bypassing the user-judgment step that phishing depends on entirely.

sequenceDiagram
    participant Attacker
    participant Dependency as Trusted Software Dependency
    participant BuildPipeline as Victim's Build/Update Pipeline
    participant Victim as Victim Organization

    Attacker->>Dependency: Compromise upstream package/library/update mechanism
    Dependency->>BuildPipeline: Victim pulls in compromised dependency (routine update)
    BuildPipeline->>Victim: Malicious code shipped as part of trusted software
    Note over Victim: No phishing email, no user judgment call required
    Victim->>Attacker: Initial access achieved silently

The practitioners specifically noted this vector is both complicated to explain to non-technical stakeholders and complicated to detect, because the compromise arrives disguised as a completely normal software update from an already-trusted source. That combination — a comparatively new vector, difficult to communicate, and difficult to detect — is exactly what makes it likely to dominate industry conversation and defensive investment through 2023.

Cloud Native Security

Described somewhat dismissively as “the new single pane of glass” — a term so broad it risks becoming meaningless. The core critique is that the industry does not yet have mature, complete tooling for continuous monitoring, detection, and incident response specifically built for cloud-native data and processes, even though organizations have already moved substantial workloads to the cloud.

“Cloud native security” as a vendor pitch essentially claims: “we understand how to secure your cloud environments” — but the practitioners argue this is currently more marketing positioning than a fully solved technical capability, because organizations are still working out how to replicate the maturity they had with on-premises network security monitoring in cloud environments.

Capability AreaOn-Prem Maturity (historical)Cloud-Native Maturity (2023 assessment)
Continuous monitoringEstablished (SIEM, NSM, IDS/IPS)Still maturing
Detection engineeringEstablished detection content librariesStill being built out per cloud provider
Incident responseEstablished playbooksCloud-specific IR still evolving
Network security monitoringMature (span ports, taps, NSM tooling)Cloud-native equivalents still emerging

The prediction/consensus here is that this gap is real and will not close quickly — likely a multi-year process before cloud security operations reach the same operational maturity that on-premises network security monitoring achieved over the preceding decades, even as “cloud native security” continues to be a heavily marketed term at every major security conference.

The Alphabet Soup: EDR, XDR, MXDR, and Beyond

This was an independent match between both practitioners, framed as the industry’s habit of continuously prefixing new letters onto “DR” (Detection and Response): EDR (Endpoint), XDR (Extended), MXDR (Managed XDR), and so on.

AcronymExpansionCore Idea
EDREndpoint Detection and ResponseDetection/response focused specifically on endpoint telemetry
XDRExtended Detection and ResponseCorrelates telemetry across endpoint, network, cloud, identity, and email into a single detection layer
MXDRManaged XDRXDR capability delivered as a managed service by a third-party provider

The practitioners’ shared critique is that every new acronym is marketed as a fundamentally new capability, when in practice the underlying idea — correlating more telemetry sources for better detection — is incremental, and adding a letter to the acronym does not by itself deliver new detection capability. The joke made in the discussion (“XYZDR… we need next-gen humans”) underscores the sentiment that the terminology treadmill has outpaced any genuinely new differentiated capability behind most of these product names.

flowchart LR
    EDR[EDR<br/>Endpoint telemetry only] --> XDR[XDR<br/>+ network, cloud, identity, email telemetry]
    XDR --> MXDR[MXDR<br/>+ managed detection/response service]
    MXDR -.->|marketing trend continues| NextGen["'XYZDR'<br/>next acronym, same core idea:<br/>more correlated telemetry"]

The consensus prediction is that vendors will continue adding acronyms throughout the year — essentially guaranteed given how entrenched this marketing pattern has become — even though the practical security capability improvements behind each new letter are often marginal.

Automated Red Teaming vs. Vulnerability Management vs. Real Red Teams

The final topic was framed as a prediction rather than a buzzword: automated red teaming products will continue to be aggressively sold by vendors in 2023, but will not meaningfully dominate the industry as an effective substitute for genuine red team engagements.

The practitioners position automated red team tooling as occupying an uncomfortable “gray space” between two well-understood, well-differentiated categories:

flowchart LR
    subgraph Clear["Clearly Differentiated Approaches"]
        VM["Vulnerability Management<br/>(e.g., Nessus-style scanning)<br/>Outcome: list of known vulnerabilities to patch"]
        RT["Manual Red Team<br/>Actively emulates real threat-actor TTPs<br/>Outcome: identifies people/process/tech gaps"]
    end
    ART["Automated Red Team Product<br/>'Gray space' — not a vuln scanner,<br/>not as effective as a real red team,<br/>doesn't adapt like a human operator"]
    VM -.->|clear scope| ART
    RT -.->|clear scope| ART
ApproachWhat It Actually DoesEffectiveness Ceiling
Vulnerability management (e.g., Nessus)Consistently scans the environment, reports known vulnerabilitiesClear, bounded outcome: a patch list
Automated red team productAutomates predefined adversary emulation scenarios/playbooksCannot adapt in real time the way a human operator can; effectiveness plateaus quickly
Manual red team engagementHuman operators actively emulate real threat-actor TTPs, adapting to defenses encounteredIdentifies genuine gaps in people, process, and technology; most effective but requires trained, skilled staff

The commercial appeal of automated red team products is straightforward to understand even if the practitioners are skeptical of their effectiveness: it is much easier to sell “push a button, save time and money, no need to train your whole team” than it is to sell the investment required to build and retain an in-house red team capability. As the practitioners note, easier-to-understand concepts tend to be more commercially popular regardless of whether they are actually as effective as the alternative.

An illustrative comparison of what each approach looks like at the tooling level:

# Vulnerability management — consistent, scheduled scanning (illustrative)
nessuscli scan --policy "Basic Network Scan" --targets 10.0.0.0/24 --schedule daily

# Automated red team — predefined adversary emulation playbook (illustrative)
automated-redteam run --playbook "credential-access-and-lateral-movement" --target-scope prod-vpc

# Manual red team — human-driven, adaptive TTP emulation (illustrative pseudocode)
# 1. Recon target environment
# 2. Select TTP based on observed defenses (adapts in real time)
# 3. Execute technique, observe detection/response
# 4. Pivot approach based on blue team reaction
# 5. Document gaps in people, process, and technology

Both practitioners agreed there may still be a legitimate, narrower role for automated red team tools: as a baseline capability that complements — but does not replace — a trained team capable of real, adaptive red team emulation and detection engineering. It is not an either/or choice; organizations still need both a baseline automated capability and genuinely trained people.

Summary

Across eight buzzwords and predictions compared independently by two security practitioners, three clear patterns emerge for 2023:

  1. Genuine industry-wide consensus exists on a few terms. AI/ChatGPT and the EDR/XDR/MXDR “alphabet soup” were independently written down by both practitioners without prompting — a strong signal that these truly dominated mainstream security conversation, for better (AI’s transformative potential) or worse (acronym-driven detection marketing with diminishing differentiation).
  2. Regulatory and observed-incident pressure sustains buzzwords longer than pure hype could. Bills of Materials (SBOM/FBOM/HBOM/BBOM) persist because of active government mandates, not because the underlying tooling ecosystem is fully mature. Likewise, OT ransomware and software supply chain attacks are grounded in real, already-observed incidents (Pipedream/INCONTROLLER, direct PLC-encryption payloads, Microsoft’s macro-blocking change reducing phishing’s dominance) rather than speculative marketing.
  3. Skepticism is warranted for categories that promise to replace trained people with automation or a single unifying label. Both “cloud native security” and “automated red teaming” were called out as terms that oversell current capability — cloud security operations tooling is still years away from on-premises-grade maturity, and automated red team products occupy a gray space that cannot substitute for either consistent vulnerability management or a genuinely adaptive, human-driven red team.

The overarching takeaway is that separating genuine technical substance from marketing language requires asking, for any buzzword: what specific capability gap does this actually close, is it grounded in observed real-world incidents or regulatory requirements, and does it attempt to replace trained security professionals rather than augment them? Terms that pass that test (SBOMs under regulatory mandate, OT ransomware grounded in observed ICS malware, supply chain attacks as a measurable initial-access shift) are worth genuine investment. Terms that fail it (an ever-lengthening detection acronym, a single “cloud native security” label, or a red team “product” that can’t adapt like a human) deserve healthy skepticism regardless of how prominently they are marketed on the conference floor.


Search Terms

security · hot · takes · buzzwords · predictions · threat · intel · networking · systems

More Security Hot Takes & Threat Intel courses

View all 21

Interested in this course?

Contact us to book it or get a custom training plan for your team.