Memory Safety Glossary
Plain-English definitions for common memory-safety, secure development, and roadmap terms used across MemorySafetyRoadmap.com.
Contents
1. Core Terms
Memory safety: A property of software where code cannot accidentally access, corrupt, or misuse memory in unsafe ways such as reading outside a buffer or using memory after it has been freed.
Memory-safe language: A language or language mode that prevents many memory errors by default through features such as bounds checks, ownership, garbage collection, strong typing, or runtime safety checks.
Memory-unsafe language: A language that gives programmers direct memory control and can permit memory corruption if code is incorrect. C, C++, Assembly, and Objective-C are common examples in memory-safety discussions.
Memory corruption: A condition where software changes memory in a way that was not intended, potentially causing crashes, data corruption, or exploitable vulnerabilities.
2. Bug Classes
Buffer overflow: Writing more data into a memory buffer than it can safely hold.
Out-of-bounds access: Reading from or writing to memory outside the intended range.
Use-after-free: Continuing to use memory after it has been released.
Double free: Releasing the same memory more than once.
Null pointer dereference: Attempting to use a memory reference that points to nothing.
Integer overflow: A numeric calculation exceeds the range the program expects. This can sometimes contribute to memory errors, for example by causing an incorrect allocation size.
Uninitialised memory: Memory is read before it has been assigned a known value.
3. Language And Runtime Terms
Ownership: A Rust concept where each value has a clear owner responsible for its lifetime, helping prevent use-after-free and double-free bugs.
Borrowing: Temporarily using a value without taking ownership of it. Rust's borrowing rules help prevent unsafe aliasing and mutation patterns.
Lifetime: The period during which a value or reference is valid. Lifetime checks help ensure references do not outlive the data they point to.
Bounds checking: Checking that a program only accesses array, string, or buffer positions that actually exist.
Garbage collection: Automatic memory management where the runtime identifies and frees memory that is no longer used. Go, Java, C#, Python, and JavaScript commonly use garbage-collected runtimes.
Unsafe block: A section of code where a language allows operations that bypass some normal safety checks. Rust supports unsafe blocks for necessary low-level work, but they require careful review.
FFI: Foreign Function Interface. A way for code in one language to call code written in another language. FFI can reintroduce memory-safety risk if safe code calls unsafe native libraries.
4. Controls And Evidence
Sanitizer: A compiler or runtime tool that helps detect memory errors during testing. Examples include AddressSanitizer and MemorySanitizer.
Fuzzing: Automated testing that sends many unexpected inputs to software to find crashes, memory errors, and security defects.
SAST: Static Application Security Testing. Tools that inspect code or compiled artefacts for potential vulnerabilities.
SCA: Software Composition Analysis. Tools that identify third-party components and known vulnerabilities.
SBOM: Software Bill of Materials. An inventory of software components and dependencies, often generated in CycloneDX or SPDX format.
CWE-1399: MITRE's CWE category for comprehensive memory safety. It can help teams classify and track memory-safety-related vulnerabilities.
Compiler hardening: Build-time and runtime protections such as ASLR, stack canaries, control-flow integrity, and FORTIFY_SOURCE. These can reduce exploitability but do not remove the underlying vulnerability class.
5. Roadmap And Compliance Terms
Memory-safety roadmap: A staged plan for reducing memory safety risk over time through language choices, safer APIs, testing, hardening, isolation, migration, ownership, and review.
Memory-safe language transition: The process of moving some new or existing code toward languages or runtime environments that reduce memory corruption risk.
CRA readiness evidence mapping: A structured mapping of questionnaire answers and generated documents to Cyber Resilience Act readiness areas. It is not CRA certification, CE marking, legal advice, or a conformity assessment.
OpenSSF Memory Safety Continuum: A model describing levels of organisational maturity in adopting memory-safe practices and reducing memory-safety risk.
Attestation JSON: In the MSCD Generator, a local JSON file containing timestamp, rules engine version, key metrics, document hashes, and PDF byte hashes. It is browser-local evidence support, not third-party proof or certification.
Self-assessment: An assessment based on user-provided answers. The output is only as accurate as the input and should be reviewed by appropriate engineering, security, and legal stakeholders.