Mainframes to PCs to Cloud to AI Accelerators: How the Threat Model Moved

Computers went from room sized machines like ENIAC (built 1943 to 1945) to IBM's compatible System/360 family (7 April 1964), minicomputers, the 1971 microprocessor, the IBM PC (12 August 1981), networked servers, x86-64, virtualization, public cloud (2006) and now GPUs, custom accelerators and unified memory chips. Each step moved the security boundary somewhere new.

Security started as a locked door. Time sharing made it about users and access control, the open PC made it about a multi-vendor supply chain and the network, cloud made it about isolation between strangers on shared silicon, and accelerators push it down into firmware, drivers and shared memory. Below is that arc with dates checked against primary sources, and what to inventory on a modern server.

Key takeaways

• ENIAC was reconfigured by rewiring; the first stored program ran on the Manchester "Baby" on 21 June 1948.
• System/360 (7 April 1964) separated software from hardware across six compatible models and made microcode a swappable layer, an early form of firmware.
• Time sharing (CTSS 1961, Multics 1965) put many users on one machine and forced access control, protection rings and audit.
• The Orange Book (DoD 5200.28-STD, 26 December 1985) graded systems D to A1; its A1 class already required trusted distribution of updates. Common Criteria (ISO/IEC 15408) replaced it internationally.
• The microprocessor (1971) and the IBM PC (1981), built from off the shelf parts with a published technical reference, created today's multi-vendor component supply chain.
• Networking made every PC a target; the 1988 Morris worm hit about 6,000 of roughly 60,000 internet hosts.
• Cloud (EC2 beta, 24 August 2006) made tenant isolation the core property, and Meltdown and Spectre (January 2018) showed shared CPUs can leak across it.
• GPUs and accelerators became general compute with CUDA (2006) and custom chips such as Google's TPU (2016). Their firmware, drivers and memory isolation are now part of the trusted base.
• HBOM and SBOM are different documents. CISA's HBOM framework (25 September 2023) covers physical parts; software, firmware versions and drivers belong in an SBOM.

A dated timeline: from ENIAC to AI accelerators

Dates marked with an asterisk come from Wikipedia summaries rather than a primary source; the rest were checked against the organisation's own page.

How the eras compare

The first electronic computers: when security was a locked door

The Computer History Museum (CHM) describes ENIAC as the first large scale computer to run at electronic speed without mechanical parts. It used almost 18,000 vacuum tubes, lost one roughly every day or two, and each new problem took many days of rewiring and switch setting. It stayed classified until The New York Times put it on the front page on 15 February 1946.

The Manchester "Baby" ran its first program on 21 June 1948, which CHM calls the first program to run on a digital, electronic, stored-program computer. Keeping instructions in the same memory as data made computers general purpose, and also meant a program could be loaded, changed or corrupted like any other data.

What security meant then. Physical and organisational control. A handful of cleared people touched the machine, the program was a wiring diagram or a deck of cards, and the threats were espionage, sabotage and error. One program never attacked another, because there was only one.

What made System/360 a turning point?

IBM launched System/360 on 7 April 1964. IBM's history says it replaced all five existing IBM product lines with one strictly compatible family, announced six processor models spanning a fiftyfold performance range plus 54 peripheral devices, and pioneered the 8 bit byte. IBM puts the cost at USD 5 billion over four years and says more than 1,000 systems were ordered in the first month.

Architecture separated from implementation

For the first time, IBM says, software written for one machine could run on any other in the line. CHM notes that the Principles of Operation manual became a classic because it separated the architecture from the details of any one model. That created the software market. It also means a flaw in the architecture or shared system software applies to every model at once, the same reason one library flaw today reaches thousands of products.

Microcode as a swappable layer

CHM explains that the smaller models used microprogramming in read only stores to implement complex instructions without expensive hardware. On the Model 30, microcode lived on punched cards in a Card Capacitor Read-Only Store; swapping a card changed the machine's capabilities, even in a customer's office, and let a Model 30 emulate an IBM 1401. This is an early, widely deployed form of firmware: code below the operating system that defines what the hardware does and can be replaced in the field. Every later debate about microcode updates and signed firmware starts here.

Multiprogramming

CHM notes that OS/360 was late, especially the multiprogramming versions that ran several programs at once. Once two programs share a machine, the system must stop one from reading or overwriting the other, so storage protection and a privileged supervisor state became essential.

What security meant then. A mainframe was a guarded corporate asset. Security meant keeping jobs apart, controlling who could submit work and change the system, and trusting one vendor for hardware, microcode and operating system. Supply chain risk existed, but it had one name on it.

How did minicomputers and time sharing change access control?

Time sharing. CHM records that MIT's Compatible Time-Sharing System (CTSS), developed under Fernando Corbató on a modified IBM 7090, was demonstrated in 1961. Dozens or hundreds of users could log in from terminals, often repurposed teleprinters on phone lines, at the same time. Multics, begun in 1965 by MIT, Bell Labs and General Electric, aimed to be a computer utility; the Multicians history says its early milestones included paging, segmentation and rings, and that it was designed to be secure from the beginning.

Minicomputers. Cheaper machines let a department own its computer. CHM lists the DDP-116, announced in 1965 at USD 28,500, as the first commercial 16 bit minicomputer, and notes that DEC's PDP-8/e of 1970, the sixth compatible generation, cost USD 6,500 and that PDP-8s ran inexpensive time sharing at Carnegie Mellon University.

Time sharing forced the access control ideas we take for granted:

• Accounts and passwords, because the machine had to know who was typing.
• File permissions and access lists, because users shared one file system.
• Protection rings, so the supervisor ran with more privilege than user code.
• Audit, to answer "who did that" afterwards.

What security meant then. The threat moved from outsiders at the door to insiders at terminals: one user reading another's files, or a program escalating to operator privileges. The Orange Book grew directly from this. Its introduction says a Defense Science Board task force was assembled in October 1967 to address safeguards in "remote-access, resource-sharing computer systems."

How did the Orange Book and Common Criteria fit in?

The Trusted Computer System Evaluation Criteria, DoD 5200.28-STD, is dated 26 December 1985 and superseded a 15 August 1983 version. Its introduction traces the path: the 1967 task force, its February 1970 report "Security Controls for Computer Systems", DoD Directive 5200.28 in 1972 and the DoD Computer Security Initiative of 1977.

Two requirements read as if written for today's supply chain debates. B2 requires covert channel analysis and configuration management of the trusted computing base. A1 requires trusted distribution: a controlled facility that keeps the master copy of the trusted code and the on site copy in step, with procedures assuring that updates to software, firmware and hardware reach customers exactly as the master copies specify. That is a 1985 statement of what signed releases and build provenance aim at now.

The Multicians history says Multics was the first system to receive a B2 rating, and for years the only one.

Other countries had their own criteria; the Common Criteria for Information Technology Security Evaluation unified them and is now adopted as ISO/IEC 15408:2022. According to Wikipedia's summary, the recognition arrangement was first signed in 1998 by Canada, France, Germany, the United Kingdom and the United States, products are evaluated against a Security Target that can draw on Protection Profiles, and there are seven Evaluation Assurance Levels. Our post on the Orange Book's path to the Common Criteria has more.

What it changed. Evaluation made assurance contractual, but an evaluated configuration is a snapshot while software changes weekly. That is why continuous evidence such as SBOMs and signed provenance matters now.

The microprocessor: computing becomes a component

CHM records that the first advertisement for a microprocessor, the Intel 4004, appeared in Electronic News in 1971. Built for the calculator maker Busicom, it had 2,250 transistors and performed up to 90,000 operations per second in four bit chunks; Federico Faggin led the design and Ted Hoff the architecture. In January 1975, Popular Electronics put the MITS Altair 8800 kit on its cover; CHM says it sold for USD 297, or USD 395 with a case.

What security meant then. For hobbyist machines, almost nothing: one user, no network, no protection between programs. The real shift was economic. Once the CPU was a catalogue part, a computer became an assembly of parts from many suppliers, and the modern hardware supply chain began.

What did the IBM PC's open architecture do for the supply chain?

IBM unveiled the 5150 Personal Computer on 12 August 1981 at the Waldorf Hotel in New York, at USD 1,565 with 16 KB of RAM and no disk drive. IBM's history explains the choices that mattered:

• Off the shelf parts. To hit a one year deadline and a USD 1,500 price, the team dropped IBM's habit of making everything. It chose Intel's 8088 processor, an operating system from Microsoft that became MS-DOS, and an Epson printer.
• Reused subsystems. About half the system, including the expansion bus, display, floppy interface and keyboard, came from the IBM System/23 Datamaster.
• An open architecture. IBM published a technical reference of the circuit designs and source code to help other companies build software and peripherals.

The result was a standard anyone could build cards, software and eventually whole compatible machines for. That openness is why the PC won, and it is the template for today's supply chain: a processor from one company, firmware from another, an operating system from a third, and dozens of devices with their own code. Our posts on bus evolution, memory evolution and motherboards, firmware and BMCs follow those components forward.

What security meant then. Early PC operating systems gave every program full access to memory and hardware, had no user accounts, and loaded software from floppy disks of any origin. The trust model was "whatever is in the drive at power on", which is the problem Secure Boot and measured boot address decades later.

When did networking make every PC a target?

Through the 1980s, PCs joined local networks and client server systems. In 1988 the Morris worm showed the consequences of connecting machines. CHM says it caused major problems for days for about 6,000 of the 60,000 hosts then on the internet, calls it the first worm to have a major effect on real world systems, and notes that Robert T. Morris became the first person convicted under the Computer Fraud and Abuse Act. See what the Morris worm changed.

As the PC became the standard desktop and the internet reached every office, any connected machine could be reached by any other. The platform kept growing: according to Wikipedia's summary, AMD announced its 64 bit extension, AMD64, in 1999, published the full specification in August 2000 and first shipped it in the Opteron in April 2003. x86-64 brought four level paging and much larger address spaces, which later made running many virtual machines on one server practical.

What security meant then. The perimeter: firewalls, desktop antivirus, operating system patches and the split between user and kernel mode. The software supply chain was mostly invisible, because code came from a few large vendors plus a pile of shareware and drivers no one inventoried. See our history of firewalls.

How did virtualization and cloud change isolation?

Virtualization

Gerald Popek and Robert Goldberg set out formal requirements for a virtualizable architecture in 1974, according to Wikipedia's summary. The x86 instruction set did not meet them cleanly, so early x86 hypervisors relied on complex software techniques until Intel (VT-x) and AMD (AMD-V) added hardware support in 2005 and 2006; IOMMUs (Intel VT-d and AMD-Vi) later extended isolation to devices.

Virtualization changed the unit of isolation. Instead of protecting users from each other inside one operating system, the hypervisor protects whole operating systems from each other on one machine, and the hypervisor, CPU extensions and IOMMU become the trusted base.

Public cloud

Amazon launched S3 on 13 March 2006 and announced the EC2 beta on 24 August 2006, describing it as "resizable compute capacity in the cloud". Servers became rented, metered capacity, with unrelated customers on the same hardware.

Providers responded by moving work off the main CPU. AWS's whitepaper on its Nitro System, for example, describes three main components: Nitro Cards, the Nitro Security Chip and the Nitro Hypervisor. It says the cards are built around an AWS designed system on a chip running purpose built firmware, separate from the host main board while sharing its power supply and PCIe interface. Whatever the provider, the isolation boundary now includes custom silicon and firmware the customer never sees.

Shared silicon leaks

In January 2018, Meltdown and Spectre showed that isolation enforced by page tables could be undone by how CPUs speculate. Google Project Zero says it reported the issues to Intel, AMD and ARM on 1 June 2017 and lists three variants (CVE-2017-5753, CVE-2017-5715 and CVE-2017-5754). The researchers' site notes that, depending on a cloud provider's infrastructure, it might be possible to steal data from other customers. Linux now reports the status of these and later issues under /sys/devices/system/cpu/vulnerabilities/. See Meltdown and Spectre explained.

What security meant then. Tenant isolation, cloud identity and access management, and keeping microcode, hypervisors and host kernels patched. The customer's share shrank to the guest and the application, while dependence on the provider's hardware and firmware supply chain grew.

Why did GPUs and accelerators become general compute?

NVIDIA's CUDA programming guide tells it briefly: GPUs became more programmable each generation, by 2003 some pipeline stages were fully programmable, and in 2006 NVIDIA introduced CUDA so any computational workload could use GPU throughput independent of graphics APIs. A GPU runs thousands of simple threads with high memory bandwidth, which suits the matrix arithmetic behind scientific computing and neural networks.

Custom accelerators followed. On 19 May 2016 Google described its Tensor Processing Unit, a custom ASIC for machine learning tailored for TensorFlow, saying it had run TPUs in its data centres for more than a year and that a TPU board fit into a hard disk drive slot. Data centres now mix general CPUs with specialised chips.

Accelerators bring their own stack of firmware, drivers, runtimes, libraries and container tooling, each with versions and vulnerabilities; our guide on enabling GPUs in Docker safely shows how much code sits between a container and a GPU.

Accelerator isolation has proved imperfect. CERT/CC Vulnerability Note VU#446598, published 16 January 2024, says GPGPU platforms from AMD, Apple and Qualcomm failed to adequately isolate process memory, so a GPU kernel could observe local memory values left by another kernel, even across processes or users. Vendors are adding confidential computing for accelerators: NVIDIA's documentation describes confidential bare metal, confidential virtual machines and confidential containers on its GPUs and CPUs, with attestation that lets a workload verify the hardware and security configuration before releasing secrets.

What security meant then. Accelerators are expensive, shared and often multi tenant. Security means memory isolation between jobs on one device, trustworthy drivers and firmware, attestation before sending data or model weights, and patching a fast moving stack of runtimes and libraries.

What do unified-memory SoCs change?

For most of the PC era, the CPU and a discrete GPU each had their own memory and data crossed a bus. System on chip designs collapse that. Apple's 10 November 2020 announcement of M1 describes one SoC combining CPU, GPU, Neural Engine, I/O and security functions, built on a 5 nanometre process with 16 billion transistors, with a unified memory architecture that puts memory in a single pool so every part of the chip can use the same data without copying. Our post on unified memory for local LLMs covers the performance side.

For security, three things change:

• One pool, many masters. CPU cores, GPU, neural engine and other blocks share physical memory, so isolation depends on each block's memory management and the operating system programming it correctly.
• Hidden boundaries. The boundary is inside the package, defined by firmware and hardware you cannot inspect.
• Firmware for every block. Each engine has its own firmware, delivered with operating system updates, so patching the OS patches much of the hardware.

Where does the hardware supply chain risk sit today?

NIST SP 800-161 Revision 1 (May 2022, updated November 2024) frames the problem: products that "may potentially contain malicious functionality, are counterfeit, or are vulnerable" because of poor manufacturing and development practices, and limited visibility into how acquired technology is built and integrated. In a modern server the risk sits in layers:

NIST SP 800-193, Platform Firmware Resiliency Guidelines (May 2018), addresses the firmware rows: protecting platform firmware against unauthorized changes, detecting changes, and recovering rapidly and securely. It warns that a successful firmware attack could leave a system inoperable, perhaps permanently. See hardware supply chain trust boundaries, the BMC firmware supply chain and counterfeit and untrusted components.

The pattern across sixty years: each era moved trust to a layer fewer people could inspect. In 1964 it was microcode on punched cards. Today it is firmware on accelerator cards, offload chips and BMCs, plus the open source drivers and runtimes that talk to them.

What do HBOMs and SBOMs each cover in a modern server?

CISA published its Hardware Bill of Materials Framework for Supply Chain Risk Management on 25 September 2023. CISA says it provides a consistent naming method for component attributes, a format for describing different component types, and guidance on what HBOM information fits each purpose. The framework is explicit about its limits:

• SBOM information is out of scope, though the framework calls it a crucial part of what purchasers need, aims for consistency with CycloneDX and SPDX, and recommends future work to merge HBOM with SBOM frameworks.
• Firmware is covered only partly. It records who provides a component's firmware but stops short of firmware provenance.
• It is captured at sale, and a new HBOM may be reasonable when the vendor changes the product version.

CycloneDX describes HBOM support for processors, embedded systems and other hardware alongside their firmware and configuration, so one format can carry both views.

In practice: ask hardware vendors for HBOMs when buying, and keep SBOMs for everything that runs, including firmware and drivers where vendors provide them. Our HBOM vs SBOM explainer covers the formats.

Decision table: which control fits which era's risk

Step by step: inventory a modern server across every era's layer

These commands only read state. They run on Linux; most need root. Store the output in your asset records next to the machine's HBOM, if you have one.

1. Identify the CPU and its microcode

lscpu | grep -E 'Model name|Socket|Thread|Virtualization'
grep -m1 microcode /proc/cpuinfo

The microcode revision is the modern descendant of the Model 30's punched cards. CPU security fixes often ship as microcode.

2. Check CPU vulnerability mitigations

grep -r . /sys/devices/system/cpu/vulnerabilities/

The kernel documents each file, from meltdown and spectre_v2 to newer entries. "Vulnerable" means a missing microcode or kernel update, or a disabled mitigation.

3. Record platform firmware

sudo dmidecode -t bios -t system
fwupdmgr get-devices
fwupdmgr get-updates

get-devices lists devices fwupd can see with firmware versions, and get-updates shows available updates. Reading is safe. Applying firmware is not: do it in a maintenance window, with power protected, after confirming the device is the one you mean.

4. Confirm the IOMMU is active

ls /sys/kernel/iommu_groups/ | wc -l
dmesg | grep -i -E 'DMAR|AMD-Vi|IOMMU' | head

Zero groups means no IOMMU isolation for devices, which matters on virtualization hosts and machines with external ports. The bus evolution post explains why.

5. Record accelerator drivers and firmware

lspci -nn | grep -i -E 'vga|3d|display|processing accelerator'
nvidia-smi --query-gpu=name,pci.bus_id,driver_version,vbios_version --format=csv

The second line applies to NVIDIA GPUs; other vendors ship their own tools. NVIDIA's documentation describes the VBIOS as the BIOS of the GPU board. Record driver and VBIOS separately, because they update on different schedules.

6. Scan the software that runs on top

safeguard scan --dir /srv/inference-service
safeguard scan --image registry.example.com/ml/inference:2026-10

This produces SBOMs and vulnerability results for the service code and the container image, including GPU runtime libraries inside the image. Results are written as JSON under ./output.

7. Describe firmware and drivers in CycloneDX

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    { "type": "device", "bom-ref": "gpu0", "name": "Example data centre GPU",
      "properties": [ { "name": "pci:address", "value": "0000:41:00.0" } ] },
    { "type": "firmware", "bom-ref": "gpu0-vbios", "name": "Example GPU VBIOS", "version": "96.00.89.00.01" },
    { "type": "device-driver", "bom-ref": "gpu-driver", "name": "example-gpu-driver", "version": "580.65.06" },
    { "type": "firmware", "bom-ref": "bmc-fw", "name": "Example BMC firmware", "version": "2.14.1" }
  ],
  "dependencies": [ { "ref": "gpu0", "dependsOn": ["gpu0-vbios", "gpu-driver"] } ]
}

Names and versions are placeholders, and the property name is a local convention. Vendor supplied SBOMs beat hand assembled ones; a file like this fills the gap, and you can scan it with safeguard scan --sbom server-firmware.cdx.json.

8. Repeat after every rebuild

A reimaged server pulls drivers, runtimes and images again. Rerun steps 1 to 7 and compare with the last record, so a downgraded driver or old base image does not slip back in.

Where Safeguard fits, honestly

Most of this history sits outside Safeguard's scope. Safeguard does not inspect silicon, verify firmware signatures, configure IOMMUs, scan firmware binaries, manage devices or generate a hardware bill of materials. It works on the software side of the HBOM and SBOM split: it scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>), matches components against vulnerability databases, applies reachability analysis, evaluates policies and gates, and shows which projects contain a given component and version. If your vendors provide SBOMs for firmware and drivers, or you assemble them as in step 7, Safeguard can ingest them alongside the images and services that run on the hardware. Fixes for silicon, microcode and device firmware still come from the vendor.

Common mistakes

• Treating hardware as static. Microcode, BMC, VBIOS and device firmware all update; the server you bought is not the server you run.
• Assuming the cloud provider covers everything. The provider owns hardware and hypervisor; you own the guest, images and dependencies.
• Inventorying parts but not code. An HBOM names the GPU, not the driver, runtime or container toolkit exposed to workloads.
• Inventorying code but not firmware. A container SBOM misses the host driver and device firmware the workload depends on.
• Reading a certification as current. An evaluated configuration describes one version at one time.
• Ignoring accelerator multi tenancy. Sharing a GPU between users needs the same isolation thinking as sharing a CPU.
• Not rechecking after rebuilds. Reimaging is when old drivers and base images quietly return.

FAQ

What was the first stored-program computer?

The Computer History Museum says the first program to run on a digital, electronic, stored-program computer ran on the Manchester "Baby" on 21 June 1948. ENIAC, finished in 1945, was electronic but programmed by rewiring.

Why was the IBM System/360 so important?

Announced on 7 April 1964, it was one compatible architecture across many models, so software ran on all of them. That created the software industry, standardised the 8 bit byte and turned computers into platforms.

What was the first microprocessor?

The Intel 4004, first advertised in 1971, with 2,250 transistors, designed for a Busicom calculator, according to the Computer History Museum.

When did the IBM PC come out?

IBM unveiled the IBM 5150 on 12 August 1981 in New York, at USD 1,565 with 16 KB of RAM.

What is the Orange Book in computer security?

The US Department of Defense Trusted Computer System Evaluation Criteria, DoD 5200.28-STD, dated 26 December 1985. It rated systems in divisions D, C, B and A and was later superseded internationally by the Common Criteria.

When did cloud computing start?

Shared computing dates to 1960s time sharing, but the modern public cloud is usually dated to 2006, when Amazon launched S3 in March and announced the EC2 beta on 24 August.

Why are GPUs used for AI?

GPUs run thousands of parallel threads with high memory bandwidth, which suits the matrix arithmetic in neural networks. NVIDIA introduced CUDA in 2006 to open that capacity to general workloads.

What is the difference between an HBOM and an SBOM?

An HBOM lists physical components with attributes such as manufacturer and part number. An SBOM lists software components and versions, including firmware and drivers where provided. CISA's HBOM framework puts SBOM information out of scope and treats the two as complementary.

Fix it without waiting for upstream

Hardware eras change, but every one since System/360 has run a growing stack of software: a GPU server today pulls drivers, runtimes, libraries and container images, and a rebuilt machine pulls them all again. Safeguard does not fix silicon or firmware, but the open source components in that stack follow the same patch cycle as any other code, and that part your team can act on now.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The local runner demo shows how to set up Safeguard's runner on your own machine, approve it with a device code and run scans from the terminal. That is the flow for a GPU server, a lab box or an isolated build host: scan the inference images and the firmware and driver SBOM from step 7 where the hardware lives.

Click through it at your own pace, or open it full screen.

The CLI demo is a real session: the Safeguard CLI reads a lodash finding and its advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval and pushes nothing. The same approve each step flow applies when a vulnerable library turns up in a model serving service or a tool that ships alongside your hardware.

Click through it at your own pace, or open it full screen.

The Claude demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude may use. Once connected, you can ask which of your projects carry a given runtime or library version from your inventory and get the answer from your own Safeguard data.

Click through it at your own pace, or open it full screen.

To try it on your own machines, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Computer History Museum: ENIAC
• Computer History Museum: 1948 timeline (Manchester Baby)
• Computer History Museum: 1961 timeline (CTSS and time sharing)
• Computer History Museum: 1965 timeline (DDP-116)
• Computer History Museum: Inside System/360
• Computer History Museum: minicomputers and the PDP-8
• Computer History Museum: 1971 timeline (Intel 4004)
• Computer History Museum: 1975 timeline (Altair 8800)
• Computer History Museum: 1988 timeline (Morris worm)
• IBM: The IBM System/360
• IBM: The IBM PC
• Multicians: Multics history
• DoD 5200.28-STD, Trusted Computer System Evaluation Criteria (NIST archive copy)
• Wikipedia: Common Criteria
• Wikipedia: x86-64
• Wikipedia: x86 virtualization
• Wikipedia: Popek and Goldberg virtualization requirements
• AWS: Announcing Amazon S3
• AWS: Announcing Amazon EC2 beta
• AWS whitepaper: The components of the Nitro System
• Google Project Zero: Reading privileged memory with a side-channel
• Meltdown and Spectre
• Linux kernel: sysfs CPU ABI, including vulnerabilities
• Linux kernel: hardware vulnerabilities
• NVIDIA: CUDA Programming Guide introduction
• NVIDIA: Confidential Computing documentation
• NVIDIA: nvidia-smi documentation
• Google Cloud blog: Google supercharges machine learning tasks with TPU custom chip
• Apple Newsroom: Apple unleashes M1
• CERT/CC Vulnerability Note VU#446598
• CISA: Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management
• CISA: HBOM Framework (PDF)
• NIST SP 800-193: Platform Firmware Resiliency Guidelines
• NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices
• CycloneDX: Hardware Bill of Materials
• fwupd: fwupdmgr manual

Last reviewed: 23 October 2026.