Memory Evolution: Core to DDR5, LPDDR, HBM and CXL, With Security Notes

Computer memory moved from mercury delay lines and Williams tubes (late 1940s) to magnetic core (Whirlwind, 1953), then to semiconductor DRAM (Intel 1103, 1970), synchronous DRAM (JEDEC, 1993), five DDR generations ending with DDR5 (14 July 2020), and now stacked HBM and CXL attached memory. Each step changed security too: remanence, Rowhammer, on die ECC, memory encryption and link encryption all arrived along the way.

Below: a dated timeline, spec tables, security notes where a hardware change had a security consequence, and read only commands to see what memory your machines have, whether ECC reports errors and whether memory encryption is on.

Key takeaways

• Core won in the 1950s because it was random access, reliable and nonvolatile when delay lines were sequential and CRT storage was fragile.
• Robert Dennard of IBM conceived the one transistor DRAM cell in 1966 (patent issued 4 June 1968). The Intel 1103 that began replacing core used a three transistor cell.
• DDR5 (JESD79-5) split each module into two independent sub channels, moved voltage regulation onto the module and added on die ECC.
• LPDDR optimises energy, GDDR per pin speed, and HBM bandwidth per package, which is why AI accelerators depend on HBM.
• CXL 2.0 (November 2020) added memory pooling and link Integrity and Data Encryption (IDE); CXL 4.0 (November 2025) reached 128 GT/s.
• ECC, on die ECC and memory encryption are three different controls. None replaces the others.
• Memory modules and CXL devices carry firmware and belong in a hardware inventory next to your SBOM.

A dated timeline of computer memory

Dates come from the Computer History Museum, IBM, republished JEDEC announcements and the CXL Consortium's press releases. JEDEC's own site refused automated requests, so some JEDEC dates (SDRAM, DDR4, HBM, LPDDR) rest on secondary summaries of its announcements; the Sources list marks them.

What came before DRAM, and why did core memory win in the 1950s?

Delay lines stored bits as pulses travelling through a medium, usually a tube of mercury or a magnetostrictive wire. Pulses circulated, so reading a word meant waiting for it to come round. Cambridge's EDSAC used mercury delay lines in 1949, and the Computer History Museum describes the later magnetostrictive delay line in the Ferranti Sirius (1961) as slow but cheap.

Williams tubes stored bits as charged spots on the face of a cathode ray tube. They were random access and fast, but the spots faded, so the tube needed constant refresh, and the tubes were temperamental. MIT's Whirlwind was first designed around electrostatic storage tubes, and their slowness and unreliability pushed Jay Forrester toward something else.

Magnetic core solved both problems. Each bit lived in a small ferrite ring on a grid of wires, its magnetisation direction holding the value. Forrester's coincident current scheme flipped only the core at the crossing of two half strength currents, so any bit was directly addressable, and core kept its contents without power or refresh. Whirlwind ran on core in 1953, and the museum's account says core "swiftly swept away competing technologies."

Core was also expensive and labour intensive at first. The museum gives early figures of about one dollar per bit and five microseconds access time, and later cores that were four times smaller, ten times faster and a hundred times cheaper. IBM's 1964 payment of $13 million to MIT for Forrester's patent was, per the museum, the largest patent settlement to that date.

Security note. Core memory is nonvolatile. A core plane pulled from a powered down machine still holds its last contents. That is the earliest version of a problem that returns later with DRAM remanence and with persistent memory: "turned off" has never reliably meant "erased".

Who invented the one transistor DRAM cell, and when did DRAM overtake core?

IBM credits Robert Dennard with conceiving the single transistor memory cell in 1966. The Computer History Museum gives the patent dates: filed 14 July 1967 and issued 4 June 1968. One transistor acts as a switch and one capacitor holds the charge that is the bit. Capacitors leak, so the charge must be rewritten many times a second. That refresh is the "dynamic" in DRAM, and it shapes every later design and attack.

The first DRAM to sell in volume did not actually use Dennard's cell. The museum explains that Intel's 1103, introduced in 1970 as a 1024 bit chip at about one cent per bit, used a three transistor cell derived from a Honeywell proposal. Mostek's 16K MK4116 adopted the one transistor cell in 1976, and by the end of the decade 64K DRAMs had appeared from Japanese and US vendors.

When did DRAM overtake core? Sources describe a transition, not a date. IBM says DRAM made core obsolete "almost instantly" and points to 1970. The museum's general timeline lists the 1103 under 1971, while its semiconductor memory entry says core stayed dominant through the mid 1970s. A fair summary: DRAM began replacing core in new designs in 1970 to 1971 and became the default by the late 1970s.

Security note. The leaky capacitor at the heart of DRAM is the root of two later attack classes. Charge lingers after power drops (remanence, behind cold boot attacks), and as cells shrink, activity in one row can disturb its neighbours (Rowhammer).

What did SDRAM change, and when did JEDEC standardise it?

Early DRAM was asynchronous: the controller toggled signals and waited a fixed number of nanoseconds. Synchronous DRAM ties operations to a shared clock, which allowed:

• Pipelining. A new command can start before the previous one finishes.
• Burst transfers. One command returns several consecutive words.
• Multiple internal banks. One bank can be opening a row while another is transferring data.

The reference summary of SDRAM history we checked states that JEDEC formally adopted its first SDRAM standard in 1993. Single data rate SDRAM ran at 3.3 V with module grades such as PC66, PC100 and PC133, named after their clock rates in MHz.

The bigger change was organisational. From SDRAM onwards, memory became a JEDEC standardised commodity: any compliant module from any maker should work in any compliant board. That is why memory got cheap, and why one standard decision, such as on die ECC or activation counting, reaches every vendor at once.

How do DDR, DDR2, DDR3, DDR4 and DDR5 differ?

Double data rate SDRAM transfers data on both the rising and falling edges of the clock. Each generation then changed prefetch, voltage, bank organisation and, with DDR5, the module itself.

DDR, DDR2 and DDR3

The first DDR generation used a 2n prefetch at 2.5 V, with the first commercial 64 Mbit chip shipping in June 1998 according to the reference summary we checked. DDR2 doubled the prefetch to 4n at 1.8 V, running the internal array slower than the I/O so the core stays power efficient while the interface gets faster. DDR3 moved to an 8n prefetch at 1.5 V and reached systems in 2007.

DDR4

The reference summary of JEDEC's announcement dates the DDR4 standard (JESD79-4) to September 2012. DDR4 runs at 1.2 V with a separate 2.5 V supply for wordline boosting, kept the 8n prefetch, and introduced bank groups: banks are split into two or four groups, and accesses that alternate between groups can be issued faster. Standard transfer rates run from 1600 to 3200 MT/s.

DDR5

JEDEC published DDR5 (JESD79-5) on 14 July 2020. The announcement, as republished, lists the main changes compared with DDR4:

• Supply voltage drops from 1.2 V to 1.1 V.
• A voltage regulator moves onto the module itself (the power management IC, or PMIC, on the DIMM) rather than living only on the motherboard.
• Each module carries two fully independent 40 bit sub channels instead of one wide channel.
• Burst length doubles to BL16.
• Bank count doubles from 16 to 32.
• On die ECC and fine grain refresh are added to cope with shrinking cells.
• Launch speed was expected at 4.8 Gbps per pin, against DDR4's end of life rate of 3.2 Gbps.

JEDEC has since revised DDR5. JESD79-5A (26 October 2021) added further reliability features. JESD79-5C (17 April 2024) expanded timing definitions up to 8800 MT/s, added Per Row Activation Counting (PRAC), and, according to the republished JEDEC announcement, deprecated Partial Array Self Refresh "to address security concerns."

DDR generations side by side

Rows before DDR4 rest on a secondary summary; treat them as orientation, not purchasing specs.

How do LPDDR and GDDR differ from desktop DDR?

LPDDR (low power DDR) is built for phones, tablets and thin laptops. It is usually soldered or on package, with narrow channels, low voltages and deep power down states. Reference summaries of JEDEC's releases give these milestones:

• LPDDR4 (JESD209-4), August 2014, up to 3200 MT/s with two independent 16 bit channels per package.
• LPDDR4X, March 2017, lowering I/O voltage from 1.1 V to 0.6 V.
• LPDDR5 (JESD209-5), February 2019, 6400 Mbit/s per pin.
• LPDDR5X, July 2021, extended to 8533 Mbit/s per pin.
• LPDDR6 (JESD209-6), 9 July 2025, with per pin rates cited from 10.6 to 14.4 Gbit/s, 12 data bits per channel, and a burst format that reserves bits for tag or ECC data stored in the array. The summary also notes CAMM2 module support.

GDDR (graphics DDR) is built for GPUs and game consoles. It runs very high per pin rates over short traces to chips soldered around the GPU. We could not confirm per generation GDDR dates or speeds on a primary source, so none are given here.

Desktop and server DDR optimises for capacity and replaceability, with socketed DIMMs and ECC options for servers.

Security note. Soldered and on package memory changes the physical attack surface. It defeats the module transplant variant of the 2008 cold boot attack, but not other paths to memory, so encryption still matters.

What is HBM and why is it central to AI accelerators?

High Bandwidth Memory stacks several DRAM dies on top of each other and connects them vertically with through silicon vias (TSVs) and micro bumps. The stack sits next to the processor, usually on a silicon interposer (often called 2.5D packaging), and talks to it over a very wide interface: 1024 bits per stack in the generations through HBM3E, and 2048 bits in HBM4, according to the reference summary of JEDEC's releases.

That width is the point: a moderate per pin rate across 1024 or 2048 pins. The result is far more bandwidth per package at lower energy per bit, which is what large model training and inference need.

All rows in this table come from a secondary summary of JEDEC announcements, because JEDEC's own site refused our automated requests. We could not confirm a separate JEDEC HBM3E standard, so it is left out.

Because HBM sits inside the accelerator package, it is bound up with advanced packaging capacity, which is why HBM supply is often the constraint on accelerator supply. We cover that in who makes high bandwidth memory and why supply is tight and in HBM and CoWoS packaging limits.

Security note. HBM moves memory inside the package, which shrinks the physical bus an attacker could probe. It is still DRAM with the same physics, and confidentiality depends on the accelerator's own confidential computing features.

What is CXL memory expansion and pooling?

Compute Express Link is an open interconnect that runs over the PCIe physical and electrical interface. The CXL Consortium's launch announcement of 11 March 2019 ratified CXL 1.0 on the PCIe 5.0 physical layer and described three protocols: an I/O protocol, a memory protocol, and a coherency interface.

CXL.mem lets a processor treat device memory as ordinary, cache coherent system memory. Three patterns follow:

1. Expansion. Add memory capacity beyond what the DIMM slots allow by plugging a CXL memory device into PCIe lanes. It usually appears as a separate NUMA node.
2. Pooling. Several hosts connect to a shared pool and are assigned slices of it. CXL 2.0 added switching and memory pooling "to maximize memory utilization", in the consortium's words.
3. Sharing. With CXL 3.0, memory can be shared between hosts and accelerators across a fabric, with coherency maintained.

The version history, from the consortium's own press releases:

Every release states full backward compatibility with earlier versions.

Security note. CXL put memory on a link that leaves the processor package and can run through switches and fabrics. That is why IDE arrived in CXL 2.0: data in flight over the link can be encrypted and integrity protected. TSP in CXL 3.1 and 3.2 extends this toward confidential computing. CXL 3.2 also adds online firmware activation, which means one more firmware image to track and keep current.

What is the difference between ECC, on die ECC and memory encryption?

ECC (system or side band ECC)

Classic ECC adds extra bits to every word on the memory bus. The Linux kernel's RAS documentation gives the usual example: a 72 bit module carries 64 data bits plus 8 extra bits. The controller computes a syndrome with a Hamming style code (the kernel doc mentions SECDED) to correct and detect errors. The kernel distinguishes:

• Correctable errors (CE): detected and corrected.
• Uncorrected errors (UE): above the correction threshold. On a critical component this is a fatal error.

The kernel doc notes that rising CE counts can predict UEs, so replace degraded modules early.

On die ECC

DDR5 puts error correction inside each DRAM chip, fixing array errors before data leaves the chip so denser cells stay reliable. It is generally not reported to the host and does not protect the bus, module or controller. A DDR5 module without the extra side band bits is not an "ECC module" in the server sense, even though its chips contain on die ECC.

Memory encryption

Memory encryption protects confidentiality, not integrity. The memory controller encrypts data on its way to DRAM and decrypts it on the way back, so a physical attacker reading the chips sees ciphertext.

• The Linux kernel's documentation for AMD Secure Memory Encryption (SME) describes pages being marked encrypted in the page tables, decrypted when read from DRAM and encrypted when written, "which protects DRAM contents from physical attacks." Secure Encrypted Virtualization (SEV) gives each guest VM its own key so that decrypted guest data exists only inside the VM. SEV-SNP adds a Reverse Map Table that enforces a one to one mapping between system and guest physical pages.
• The kernel's Intel TDX documentation says TDX uses Intel Multi Key Total Memory Encryption (MKTME) to protect VMs cryptographically, with a range of key IDs reserved for trust domains.
• On the kernel doc's account, Linux can turn SME on with mem_encrypt=on only if firmware has enabled the feature first.

Which memory changes came with security consequences?

Remanence and cold boot (2008)

"Lest We Remember", by Halderman and colleagues at USENIX Security 2008, showed that DRAM keeps its contents for seconds after power loss even at room temperature, and much longer when cold. Their measurements: with canned air cooling the chips to about minus 50 degrees Celsius, fewer than 1 percent of bits decayed after ten minutes without power; in liquid nitrogen, decay was 0.17 percent after an hour. They recovered keys and defeated several popular disk encryption products, even on laptops that were screen locked or suspended.

The lesson for today: keys live in RAM while a disk is unlocked. Shut down or hibernate rather than sleep when a device travels, use pre boot authentication, and prefer memory encryption. See CWE-1330: remanent data after memory erase.

Disturbance errors and Rowhammer (2014)

Kim and colleagues at Carnegie Mellon and Intel Labs published "Flipping Bits in Memory Without Accessing Them" at ISCA 2014. Repeatedly activating one DRAM row corrupted data in nearby rows. They induced errors in 110 of the 129 modules they tested, from three major manufacturers, needing as few as 139 thousand accesses, and found up to one in every 1.7 thousand cells susceptible. The root cause was repeated wordline toggling accelerating charge leakage in neighbouring rows.

The standards response took years. DDR5's JESD79-5C revision in April 2024 added Per Row Activation Counting, which counts activations per row and lets the DRAM signal the controller to pause and make time for mitigation. JEDEC's announcement frames PRAC as data integrity work and does not use the word Rowhammer, but it targets exactly the row activation behaviour the 2014 paper described.

Denser cells, on die ECC and refresh features

On die ECC in DDR5 exists because cells became small enough that raw error rates rose. It improves reliability but can also hide early warning signs, because errors corrected inside the chip may never reach the operating system's counters. Separately, the JESD79-5C announcement deprecates Partial Array Self Refresh "to address security concerns" without detailing them, a reminder that features leaving parts of memory unrefreshed interact with remanence and integrity assumptions.

Memory leaves the package: CXL

CXL attached memory travels over links, switches and potentially shared fabrics. IDE (CXL 2.0) and TSP (CXL 3.1 onward) are the security answers. If your servers use CXL memory, check whether IDE is supported and enabled end to end, not only whether the device enumerates.

Firmware on memory devices

DDR5 modules carry an on module voltage regulator and serial presence detect (SPD) configuration data. CXL memory devices are full PCIe endpoints with their own controller firmware, and CXL 3.2 defines online firmware activation. Each of these is a component with a version, a vendor and an update path. That is a supply chain fact, and it belongs in a hardware inventory.

What comes next: DDR6, LPDDR6 and HBM4

• LPDDR6 was published on 9 July 2025, per the reference summary of JEDEC's release, with in array tag or ECC bits in its burst format.
• HBM4 is published (April 2025 per the same kind of summary), doubling the interface to 2048 bits per stack. That keeps HBM tied to advanced packaging capacity.
• DDR6 is in development. Secondary sources mention target data rates and a 2027 timeframe, but we could not confirm a published JEDEC DDR6 standard, so treat any DDR6 numbers you see as provisional.
• CXL is at 4.0 with 128 GT/s. The consortium's site points to ongoing work on pooling and sharing CXL memory for AI inference.

Step by step: inventory memory and check its security features

The commands below are read only. They report what is installed and what is switched on; none of them changes configuration or erases data. Keep the output with your hardware records.

1. List physical modules

On Linux, dmidecode reads the firmware's SMBIOS tables:

# Module type, size, speed, manufacturer, part number, serial
sudo dmidecode -t memory | grep -E "Size|Type:|Speed|Manufacturer|Part Number|Serial Number|Locator" | grep -v "No Module"

# Memory blocks the kernel has online
lsmem --summary

On Windows, in PowerShell:

Get-CimInstance Win32_PhysicalMemory |
  Select-Object BankLabel, Capacity, Speed, Manufacturer, PartNumber, SerialNumber, SMBIOSMemoryType

On macOS:

system_profiler SPMemoryDataType

On Apple silicon Macs and most phones, memory is on package LPDDR, so the output shows total capacity and type rather than slots.

2. Check ECC error counts

If the platform has ECC and an EDAC driver is loaded, the kernel exposes counters at the paths documented in its RAS guide:

# Per memory controller
grep -H . /sys/devices/system/edac/mc/mc*/ce_count /sys/devices/system/edac/mc/mc*/ue_count

# Per DIMM
grep -H . /sys/devices/system/edac/mc/mc*/dimm*/dimm_ce_count 2>/dev/null

If the edac directory does not exist, either the platform has no ECC or no EDAC driver is loaded for this memory controller. The rasdaemon package provides ras-mc-ctl --summary and logs events over time, which is easier for fleets than reading sysfs.

3. Check memory encryption status

# CPU feature flags (names vary by vendor and kernel version)
grep -o -w -E "sme|sev|sev_es|sev_snp|tme" /proc/cpuinfo | sort | uniq -c

# What the kernel actually enabled at boot
sudo dmesg | grep -i -E "memory encryption|SME|SEV|TME"

# Kernel command line, to see whether mem_encrypt was set
cat /proc/cmdline

A CPU flag means the processor supports a feature. It does not mean firmware enabled it or the kernel is using it. The dmesg lines are the better evidence, and the kernel documentation is explicit that Linux cannot turn SME on if firmware has not enabled it.

4. List CXL memory devices

On Linux systems with CXL support, the kernel exposes devices on the CXL bus, and the cxl tool from the ndctl project lists them:

ls /sys/bus/cxl/devices/ 2>/dev/null
sudo cxl list -M 2>/dev/null
numactl --hardware

A CXL memory expander usually shows up as an extra NUMA node with no CPUs attached.

5. Record it as inventory

Put the results into the same record you keep for software. A minimal CycloneDX style hardware entry might look like this (field values are examples):

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "device",
      "name": "DDR5 RDIMM 64GB",
      "supplier": { "name": "Example Memory Co" },
      "version": "PN-EXAMPLE-1234",
      "properties": [
        { "name": "memory:slot", "value": "CPU0_DIMM_A1" },
        { "name": "memory:speed_mts", "value": "4800" },
        { "name": "memory:ecc", "value": "sideband" }
      ]
    },
    {
      "type": "firmware",
      "name": "CXL memory expander controller firmware",
      "version": "2.3.1"
    }
  ]
}

CycloneDX describes its hardware bill of materials capability as capturing "detailed inventories of physical hardware components and associated firmware." For how this relates to software SBOMs, see HBOM vs SBOM.

Where Safeguard fits, honestly

Safeguard does not inspect DIMMs, read SPD data, scan firmware binaries or generate hardware bills of materials, and it turns on none of the ECC, encryption or CXL features above. The overlap is the software around the memory: rasdaemon, ndctl, kernel drivers and management agents ship as packages inside OS and container images. Safeguard scans repositories, images and SBOM files, including vendor supplied ones, matches components against vulnerability databases, and shows which projects carry a given component and version. If you rebuild a server image to add CXL tooling, or receive an SBOM from a hardware vendor, safeguard scan --image <name> or safeguard scan --sbom <file> tells you what is in it and what needs attention.

Common mistakes

• Assuming DDR5 means ECC. On die ECC is not side band ECC. If you need corrected and uncorrected error reporting, buy modules and platforms that support full ECC.
• Reading a CPU flag as proof of encryption. sme or tme in /proc/cpuinfo shows capability. Check firmware settings and boot logs for what is actually enabled.
• Ignoring correctable error counts. The kernel's own RAS guide says CEs can predict UEs. Alert on rising counts per DIMM, not just on crashes.
• Treating sleep as safe for a laptop with an unlocked encrypted disk. Keys stay in RAM. The 2008 cold boot paper is still the clearest demonstration of why.
• Enabling CXL memory without checking IDE. Pooling and sharing put memory on a link. Confirm what link protection your devices and switches support.
• Leaving memory device firmware out of patch management. Module regulators and CXL controllers have firmware and update paths. Track them like BIOS and BMC firmware.

FAQ

What was computer memory before RAM chips?

Delay lines, CRT based Williams tubes and, from 1953, magnetic core. Core stayed dominant until DRAM displaced it in the 1970s.

Who invented DRAM?

Robert Dennard at IBM conceived the one transistor cell in 1966; the patent issued on 4 June 1968. Intel's 1103 of 1970, the first big DRAM success, used a three transistor cell.

When did DDR5 come out?

JEDEC published the DDR5 standard, JESD79-5, on 14 July 2020.

Is DDR5 on die ECC the same as ECC memory?

No. On die ECC works inside each chip and is generally invisible to the OS. Server ECC adds bus bits so the controller can correct and report errors.

What is the difference between LPDDR5 and DDR5?

LPDDR5 is soldered or on package with narrow channels and low voltages for battery devices. DDR5 targets socketed, high capacity modules.

Why do AI chips use HBM instead of GDDR?

A 1024 or 2048 bit interface per stack gives far more bandwidth per package at better energy per bit, and large models are bandwidth bound.

What is CXL memory pooling?

Several servers draw memory from a shared pool over CXL links instead of each holding DIMMs for its peak. CXL 2.0 introduced it in November 2020.

Does CXL encrypt memory traffic?

CXL 2.0 added link level Integrity and Data Encryption (IDE), which protects data on the CXL link. Whether it is active depends on host, switches and devices.

Fix it without waiting for upstream

Memory hardware itself is outside any software scanner's reach, but the stack that runs on it is not. Server images that add CXL tools, kernel drivers and RAS daemons, accelerator hosts that pull large dependency trees, and vendor supplied SBOMs for memory devices all carry open source components that need the same patch discipline as your application code.

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.

To try it on your own machine, download Safeguard from https://safeguard.sh/download and see the CLI documentation at https://docs.safeguard.sh/docs/cli .

See how Safeguard would help

The first demo sets up Safeguard's local runner on your own machine, approves it with a device code, and runs a scan from the terminal. On an image build host, the same flow shows which packages went in after you add tools such as rasdaemon; it covers software, not the DIMMs.

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

The second demo is a real Safeguard CLI session: asked to fix a lodash CVE, it reads the finding and 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 to dependency upgrades in the tooling that builds server images.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. That lets you ask which projects carry a given package version while controlling what the assistant can touch.

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

Quick check

Sources

• Computer History Museum: Memory and storage timeline
• Computer History Museum: Magnetic core memory
• Computer History Museum: MOS dynamic RAM competes with magnetic core memory on price
• Computer History Museum: Semiconductor RAMs serve high speed storage needs
• IBM: DRAM history
• JEDEC DDR5 (JESD79-5) announcement, 14 July 2020, as republished by Design and Reuse
• JEDEC JESD79-5C announcement, April 2024, as republished by Silicon UK
• CXL Consortium: news and press releases
• CXL Consortium: launch and CXL 1.0 press release, 11 March 2019 (PDF)
• CXL Consortium: CXL 2.0 press release, 10 November 2020 (PDF)
• CXL Consortium: CXL 3.0 press release, 2 August 2022 (PDF)
• CXL Consortium: CXL 3.1 press release, 14 November 2023 (PDF)
• CXL Consortium: CXL 3.2 press release, 3 December 2024 (PDF)
• CXL Consortium: CXL 4.0 press release, 18 November 2025 (PDF)
• Linux kernel documentation: AMD memory encryption
• Linux kernel documentation: Intel Trust Domain Extensions (TDX)
• Linux kernel documentation: Reliability, Availability and Serviceability (RAS)
• Halderman et al., Lest We Remember: Cold Boot Attacks on Encryption Keys, USENIX Security 2008 (PDF)
• Kim et al., Flipping Bits in Memory Without Accessing Them, ISCA 2014 (PDF)
• CycloneDX: Hardware Bill of Materials
• Wikipedia: High Bandwidth Memory (secondary summary of JEDEC announcements)
• Wikipedia: LPDDR (secondary summary of JEDEC announcements)
• Wikipedia: Synchronous dynamic random access memory (secondary summary)
• Wikipedia: DDR4 SDRAM (secondary summary of the JEDEC release)

Last reviewed: 23 October 2026.