Why computer security is hard

NOTE: ⚠️ Some passages examine lower-level technical details. The ⚠️ symbol marks optional paragraphs or entire sections. You can skip these if you prefer a broader explanation without losing the main argument.

Introduction

Software can appear finished long before anyone has established how it behaves when conditions turn hostile. AI-assisted tools can help build interfaces and working features quickly, but a demonstration exercises only the paths selected for it. It says little about whether a request from the wrong account is refused, whether a malformed file can trigger a serious defect, or whether a failed dependency leaves information exposed. Demonstrating useful behaviour and establishing trustworthy limits require different evidence.

A system must enforce its limits despite mistaken instructions, stolen credentials, changing state and deliberate attempts to make it fail. Those limits extend beyond the application's visible features into identity systems, privileged services, libraries, operating systems, hardware and maintenance. Each component may appear to behave correctly while a missing decision between them permits a harmful result.

Security is commonly discussed in terms of confidentiality, integrity and availability: preventing unauthorised disclosure, preventing unauthorised alteration, and keeping services usable under defined conditions. These labels identify outcomes, not safeguards. A medical record, an account balance and a transport timetable each have different rules and consequences. The work begins by identifying what must be protected, which actions could violate its requirements and which routes those actions might take. Collecting and retaining less sensitive information can also reduce the harm of a later breach, even where access controls are otherwise sound. [1]

A security control is only as useful as the operations it actually governs. A website may block an unauthorised download while an export function releases the same record. Encryption may protect a file while its decryption key is accessible to an unintended party. An application may approve one file and subsequently open another under the same name. In each case, a local safeguard can suggest that the complete operation is protected when it is not.

A threat model identifies what needs protection, what an attacker can change, where privileged decisions occur and which assumptions might fail. It helps expose possible routes to harm without claiming to predict every attack. [2]

Identifying those routes also reveals the system's attack surface: the places where an attacker might supply input, request an operation or obtain information. Network services, sign-in and administrative interfaces, and file import functions are all possible entry points, even when they are not obvious on the screen. Reducing this surface means disabling unnecessary functions and services, limiting who or what can reach those that remain, and withholding permissions they do not need. Fewer exposed paths can reduce opportunities for attack, but the remaining ones still require sound checks and maintenance.

Where security first fails

Many serious incidents require no extraordinary technique. Accounts still exist with passwords supplied by the manufacturer, shared between people or reused across unrelated services. Once an attacker learns such a password, the system may accept the login exactly as designed. Password guessing, automated attempts using credentials leaked elsewhere and fraudulent requests for one-time codes exploit weaknesses around identity rather than errors in the code that checks passwords. Unique, difficult-to-guess credentials, sound account recovery, rate limits and stronger sign-in methods can reduce those opportunities. Multi-factor authentication and passkeys offer important protection, but no sign-in method can independently decide whether an instruction issued after login is sensible or legitimate. [3] [4]

People sometimes forget a password or lose the device they use to sign in. A service needs a way to help them regain access, but must also distinguish the rightful account holder from someone trying to take over the account. If resetting access requires only information that others can easily obtain, an impostor may bypass even strong sign-in protections. Account recovery must therefore provide a practical route back for legitimate users without offering an easier route to attackers.

Signing in is only the beginning of protecting an account. To avoid demanding a password or passkey for every action, many services issue a session identifier or access token that represents an authenticated session. If an attacker obtains a reusable credential of that kind, the service may accept requests as the signed-in account without requiring the original login factors again. This is session hijacking. Security therefore depends on how sessions are issued, stored, limited, expired and revoked, especially after suspected compromise or account recovery. Strong sign-in protection and protection of the authority retained after sign-in are distinct responsibilities. [5]

Social engineering attacks the human part of the decision. A message can claim that a supplier has changed bank details, that an account must be verified urgently or that a document is waiting behind a sign-in page. The malicious link may lead to a convincing imitation of a legitimate service, or a download may attempt to exploit a vulnerable application. Merely opening a web address is not equivalent to surrendering an account or infecting a computer: the result depends on the destination, the browser and device protections, the software version and what happens next. The important distinction is between a page arriving over a protected connection and the page being trustworthy. Encryption can protect data in transit to the site actually contacted; it cannot establish that the site is the one a person intended to visit. [3]

Phishing is not simply a test of whether a person can recognise a suspicious message. Zhuo and colleagues' 2023 SoK reviewed 52 empirical studies and organised factors associated with susceptibility around individual characteristics, situational conditions and the circumstances in which a message is received. Its synthesis does not support a universal profile of who will be deceived. Protection therefore combines appropriate authentication, interface design, confirmation procedures for consequential instructions and training, rather than assuming vigilance alone will always succeed. [6]

Configuration can either expose a system unnecessarily or reduce what an attacker can reach. A folder intended for one team may be left public, a management interface may be reachable from the internet when it should be internal, a database may retain a default credential, or a test environment may hold real data under weaker restrictions. These are misconfigurations: the software may behave exactly as programmed while its settings allow access or operations that were never intended. Unsafe defaults, copied settings and accumulated exceptions all contribute to the risk.

Deliberate configuration can instead reduce the attack surface. This is known as hardening: enabling only necessary services and capabilities, restricting how they can be reached and checking that the restrictions take effect. An SSH service used to administer a server remotely, for example, can be limited to authorised accounts and approved network paths, configured to disallow direct root login on Unix-like systems and, where suitable, use key-based sign-in instead of passwords. If remote administration is not needed, SSH can be disabled altogether. These measures remove or narrow ways of reaching the service, but cannot establish that the remaining code is free from vulnerabilities. Hardening must also preserve legitimate access and be verified on the actual deployed system. [4]

Credentials are also broader than passwords. Software services use secret keys and access tokens to communicate with one another, and employees or contractors may have powerful administrative accounts. A key accidentally published in a code repository, included in a log or retained after a supplier's contract ends can give access without any attempt to break encryption. Encryption cannot prevent disclosure if an attacker obtains the necessary decryption key or controls a service authorised to reveal the plaintext. Protecting stored information therefore depends on key handling and access to decryption, not only on the algorithm. An organisation may also give routine staff far more access than their duties need. The proper response involves controlling where credentials are kept, limiting their scope, withdrawing them when no longer required and being able to identify suspicious use. Logs can help establish what happened, although logging alone cannot prevent misuse and may introduce its own sensitive information if carelessly designed. The underlying concern is the same as with default passwords: a technically valid credential can provide authority well beyond the purpose for which it should have been issued. [2]

These cases share an important feature: an accepted credential, a plausible message or a permissive setting can lead to an action no one meant to authorise. Protecting the decision involves more than warning people to be careful. Services can limit guessing, make high-risk permissions exceptional and provide independent confirmation for consequential changes. A further difficulty is ensuring that those controls govern the real operation, including when a more powerful component acts on another party's behalf.

Identity, permission and delegated authority

Authentication establishes which account or other identity a request appears to come from. Authorisation decides what that identity may do with a particular record or operation. An employee may be signed in correctly and still have no right to read another employee's files. Knowing a record number or possessing a link is not, by itself, permission to retrieve the record. A system that hides an export button but leaves an underlying interface free to export the same information has protected the screen rather than the operation. Every relevant route, including direct requests, background jobs and internal services, must carry the necessary permission decision to the point where the protected effect occurs. [7]

The confused-deputy problem arises when software uses its own broader permissions to carry out a request that the caller is not entitled to make. For example, a records service may be authorised to read every file while an ordinary user should retrieve only their own. If the service accepts any record identifier without checking the caller's rights, it may return someone else's information. The user never acquires the service's master permissions; the service misuses them on the user's behalf. Isolating the protected records is therefore insufficient if a privileged intermediary will fetch them for anyone who asks. [8]

A sound delegation interface narrows the work the privileged component agrees to do. Rather than accepting an unrestricted file path, it can accept a specific permitted operation tied to the caller's rights, or a narrowly scoped capability that proves authority over a particular resource. This is an application of least authority: accounts, components and services receive only the access and operations their duties require. It also limits the blast radius of a mistake, meaning the information and actions a failure can affect, including through other components willing to act on its behalf. A component may have no direct access to private files and yet expose those files indirectly through a more powerful service if its requests are insufficiently constrained. [9] [10]

Authority cannot be settled solely by technical identity. A legitimate employee can receive fraudulent instructions to change payment details, and a genuine administrator can approve a dangerous configuration. The computer may correctly verify the employee's account while having no basis to trust the claimed origin of the business request. For high-consequence changes, confirmation using independently established contact details can provide assurance that the instruction came from the intended party. Such procedures help with fraudulent instructions but do not cure a missing authorisation check within the application. Distinct weaknesses need distinct protections.

A further danger is deliberate misuse of access that was legitimately granted. Someone may be correctly signed in and permitted to view sensitive records but still disclose them to an unauthorised party, or use an administrative capability for a harmful purpose. Authentication and authorisation may both operate as configured; they cannot establish a person's intentions. Narrow permissions, separation of sensitive duties, appropriate records of consequential actions and independent review can limit or expose this kind of insider misuse. [11]

Permission to perform an operation does not establish that the operation is valid at every stage of a larger process. An order must not advance to fulfilment before required payment conditions are met. A voucher intended for one use must not be redeemed repeatedly merely because each request is well formed and comes from an eligible account. These are business-logic failures: the application has not enforced the prerequisites, valid sequence or limits governing related actions. Such rules must be checked against authoritative state at the consequential transition, rather than inferred from a displayed screen or a step claimed by the requester. The flaw can exist without a race, malicious command or stolen account. [12]

When a correct check no longer applies

A permission check can be correct when performed and still cease to protect a later action. A file may be approved and then replaced before the program opens it. Two workers may each see sufficient stock and then both consume it. These are time-of-check to time-of-use (TOCTOU) problems: the state inspected is no longer the state on which the consequential operation acts. They become security vulnerabilities when another party can exploit the gap to violate a required rule. Some arise from concurrent operations; others concern resources whose identity or permissions change while work is under way. [13]

Consider a program that checks a file path against an approved location, then opens that path later. If an attacker can change what the path names in the interval, the program may process a different file from the one it approved. The remedy is to make the decision apply to the resource and state actually used. Depending on the system, that may mean operating on an already opened and verified file handle, using an atomic operation or transaction, holding a suitable lock, or defining how revocation affects work already begun. Repeating a check without closing the next gap is not a guarantee.

Concurrency creates related failures beyond file access. Several individually valid requests may collectively exceed an account limit if they are checked against out-of-date state. A privilege may be revoked while a long-running job is executing, or an identifier may be reassigned while another component assumes it still refers to the same object. A secure design must specify which state is authoritative and how the check and consequential operation remain consistent.

When information is allowed to direct the work

Programs process data supplied through user requests, imported files, network messages and other services. A value can be well formed and still be inappropriate for the operation it controls. A file name can lead outside an intended folder. A record identifier can select another person's data. A small compressed file can expand into an enormous amount of work. Calling such material untrusted input means that the properties needed for its particular use have not yet been established. It does not mean that every sender is malicious. The same flaw may be reached through deliberate manipulation, a corrupted file or an ordinary mistake. [14]

A dangerous transition occurs when data is allowed to become an instruction. A database query or operating-system command assembled by joining program text with an external value may let that value alter the command itself. This is an injection vulnerability. A web page can fail similarly when externally supplied text is incorporated into content that a browser interprets as code instead of displaying it as text. This is cross-site scripting; preventing it requires handling the content for the specific context in which the browser will interpret it. Safer interfaces keep the intended operation separate from the variable data, such as using parameterised database queries where the interface supports them. The solution is not a generic list of suspicious characters: a value that is safe as plain text can be unsafe when interpreted as a command, a file path or part of another language. Even a correctly constructed database query still needs a separate check that the requester is authorised to obtain its result. [15] [16]

Some harmful inputs contain no command at all. A media decoder may be asked to allocate more memory than intended, a complex document may consume excessive processing time, and repeated permitted requests may overload a shared service. Resource limits must be enforced before and during costly work, not after the cost has already been paid. The resulting failure may be a controlled refusal, a crash or a service that becomes unavailable to other users. This is why security also concerns whether systems can keep doing their legitimate jobs. The conditions under which a service promises to remain available, and the limits of that promise, deserve as much precision as its access rules. [14]

These failures differ in where untrusted information crosses a boundary. Sometimes it is interpreted as an instruction, sometimes it exhausts a resource, and sometimes it is processed by code that cannot safely manage its own memory. The last case deserves separate attention because a malformed file or message may exploit how a program stores and accesses data even when the input contains no command.

Memory safety and language guarantees

Every running program needs working storage, called memory. The program places values in areas set aside for them, uses those values and eventually releases storage that is no longer needed. A basic requirement is that one operation must not read or write outside the area assigned to it. Another is that storage must not continue to be used as though it belonged to an object after that object's lifetime has ended. These two protections are central to memory safety. They concern the validity of memory operations, rather than whether a person had permission to request the work in the first place.

The filing clerk (see How computers work: Feynman’s high-speed filing clerk) provides a direct analogy. A filing tray has space for 100 cards, but an instruction demands that 120 be inserted. Without a rule enforcing the tray's boundary, the extra cards may be placed where other records belong. In a computer, an unchecked write beyond an allocated region can corrupt unrelated data; an unchecked read may expose information from another region. Depending on the program and the surrounding protections, the consequences can range from a crash or incorrect result to a vulnerability an attacker can exploit. A checked operation instead stops the invalid access. The requested filing task may fail, but this particular boundary is preserved. The cards are a metaphor for memory locations, not a claim that every overflow automatically gives an attacker control.

A different memory error arises when a program keeps a reference to an object after that object's storage has been released. If the same region is later reused for another object, the stale reference may read or overwrite unrelated information. This is a use-after-free error. A bounds check alone cannot make the access valid: the address may fall inside an allocated region, but the object that originally made the reference meaningful no longer exists. Spatial and lifetime protections address different failures.

Older, widely used systems languages such as C and C++ permit forms of direct memory manipulation for which the programmer must establish the needed bounds and lifetime rules. That control has enabled important software, but mistakes along unsafe paths can be severe and difficult to detect. Careful implementation, code review, automated analysis, protective compiler options and testing reduce risk; they do not make every possible execution safe by definition. Nor does finding C or C++ in a product prove that the product is vulnerable. The meaningful questions concern the particular code handling relevant input, what checks or protections it uses and what power that code possesses if an error occurs.

Memory-safe language facilities move some of the burden into rules enforced by the language or its runtime. Safe Rust rejects many invalid references before a program runs and checks indexed accesses as needed. Ordinary safe Swift facilities enforce bounds and managed lifetime constraints. Python application code typically operates on managed objects rather than doing raw pointer arithmetic. These languages do not remove the need for correct security decisions, and their protections do not necessarily extend through every native component. Rust has explicitly unsafe regions; Swift may call C libraries or use unsafe pointers; Python may load native extensions. A memory-safe application that passes data to memory-unsafe code inherits the need to examine that boundary and the code beyond it. Language choice changes important classes of risk, but a product must be judged by the operations it actually performs. [17] [18] [19]

Szekeres, Payer, Wei and Song's 2013 SoK examined how memory-corruption exploits develop and what different defences try to interrupt. Their analysis distinguishes preventing invalid memory operations, detecting corruption and making exploitation harder after a defect occurs. These are materially different guarantees. The paper predates newer compiler and hardware mitigations, but its classification explains why blocking an exploit technique does not prove that the underlying memory defect has been removed. [20]

Safer languages help, but existing systems cannot simply be replaced overnight. C and C++ are deeply embedded in operating systems, firmware and specialist libraries, many of which face performance, hardware or compatibility constraints. Rewriting them may introduce defects of its own, and teams need the skills and tools to validate replacements. That does not justify accepting unsafe memory handling indefinitely. The practical assessment is where untrusted data reaches unchecked operations, which native dependencies remain, what privileges those components have and how testing, mitigations and maintenance address the risk. A language label alone cannot answer those questions. [2]

When the design is vulnerable

Design vulnerabilities can be every bit as serious as defects in memory handling or sandbox enforcement. They arise when a system's intended rules or workflows permit a harmful result, even though the software correctly follows those rules. Memory-safe code, carefully restricted components and strong encryption do not compensate for a design that grants the wrong person access to a protected operation.

Imagine a fictional encrypted-backup service. Its recovery feature requires users to sign in, but then returns the recovery key for any backup identifier they supply, without checking whether the backup belongs to them. An attacker with an ordinary account who learns another customer's identifier can obtain that customer's key. No encryption is defeated, no memory is corrupted and no sandbox is escaped. The system hands over the secret because the design never required the authorisation check that mattered.

Cryptography offers another example of a correct safeguard applied to an incomplete security decision. Encryption can protect information travelling between computers without establishing which service is at the other end or whether a request should be accepted. Those require separate checks. A protocol sets out the messages and checks that communicating systems are expected to use; the implementation is the software that follows those rules. An implementation may omit a required check, while a protocol may itself leave out a necessary requirement. Correct operation of one safeguard therefore does not establish the security of the complete operation. [21]

Consider a program connecting to a website. It may establish an encrypted connection and accept a certificate from a trusted issuer without checking whether that certificate identifies the website it meant to reach. The encryption works, but the program may be talking to an impostor. A similar mistake occurs with signed access tokens, digital credentials that some services use to decide whether to accept requests. A program might verify the token's signature but not check whether it came from an accepted issuer, was meant for this service or is still valid. In both cases, one correct check leaves another necessary decision unresolved. Neither failure requires broken encryption or a forged signature. Ross Anderson's Why Cryptosystems Fail examines the broader gap between cryptographic protections and the failures of real systems. [22] [23] [24]

Clark and van Oorschot's 2013 SoK of SSL and HTTPS surveyed how certificate issuance, browser trust decisions and infrastructure practices affected the security of encrypted connections. Their study placed identity and certificate trust within the wider system instead of treating encryption as sufficient on its own. It examined the mechanisms of its period, not today's TLS deployments or subsequently introduced protections; current implementations require evaluation against current standards. [25]

Secrets can also leak through behaviour that was never intended as an answer. Different error messages may reveal whether an account exists. A check that takes different amounts of time depending on a secret may, if that difference can be observed reliably, leak information through a timing side channel. These exposures can occur without a direct request for the secret or a broken encryption algorithm. Not every measurable difference is exploitable; the signal, the conditions and what can be inferred all matter. [26]

Security differs from ordinary fault handling because an attacker may deliberately create conditions that a designer considered unlikely. A malformed input, an unusual sequence of requests or a compromised dependency can be tried repeatedly until one route produces the desired effect. Routine tests show how known cases behave; they do not establish that all malicious combinations have been excluded. The question is which safeguards remain effective when an assumption fails.

A design vulnerability can also be built into a protocol: an implementation may follow its rules faithfully even if those rules leave a way to replay, redirect or misuse an otherwise valid message. Ross Anderson and Roger Needham explored this adversarial perspective in Programming Satan’s Computer. [27] Even correctly specified and implemented software depends on hardware preserving the boundaries it expects.

When the hardware itself is vulnerable

Software depends on hardware enforcing basic restrictions. One program should not be able to alter another program's protected memory, information restricted by the processor should remain inaccessible, and a device should start from a trustworthy state. But processors, memory chips and the low-level code that starts a device are themselves complex engineered systems. Their behaviour may undermine a security rule even when the application above them is correctly written.

⚠️ Rowhammer demonstrates an unexpected physical weakness. In some memory chips, repeatedly accessing particular memory locations can electrically disturb neighbouring cells until stored bits change. The software did not request those changes. Researchers have shown that on susceptible systems, and under particular conditions, this effect can be exploited to bypass memory protections and obtain higher privileges. A program may obey the rules about where it is allowed to write, yet the physical memory can still change information outside those limits. Rowhammer does not affect every memory design equally, and its practical exploitability and mitigations depend on the hardware and system. [28] [29]

⚠️ Other hardware weaknesses can reveal information without changing it. Modern processors sometimes perform work in advance, predicting which instructions will be needed to save time. This is called speculative execution. If the prediction proves wrong, the tentative result is discarded, but traces of that work may remain in a cache, a small store that helps the processor retrieve recently used information quickly. Measuring those traces can sometimes reveal secrets that the program was not permitted to read. Spectre exploits manipulated predictions to induce such disclosures; Meltdown exploited a different weakness in how some processors handled protected data before an access violation took effect. These are processor side channels, related to the timing leaks described earlier. They concern how a processor internally carries out instructions, not simply the published instruction set describing which operations software may request. The affected processors, conditions and countermeasures differ. [30] [31] [32]

Security can also fail before an operating system starts. Secure boot establishes a chain of trust by checking that successive stages of startup are authorised before they run. Some devices store the earliest boot code in read-only memory (ROM), which is not ordinarily rewritable after manufacture. That makes later tampering harder, but it also means a defect in the original verification or recovery routine may be impossible to repair in ROM.

⚠️ The 2018 Fusée Gelée disclosure of a Tegra X1 recovery-mode vulnerability illustrates a flaw reachable through physical USB access, not a remote network service. Software changes and operational restrictions may reduce exposure, but they cannot rewrite genuinely immutable boot ROM. Secure boot remains valuable within the guarantees of its root of trust and the attack conditions it covers. [33] [34] [35]

⚠️ Glosner and Machiry's 2026 SoK examined 43 bootloaders in the software boot chain following the hardware-rooted handoff. Its BOOTBENCH dataset collects 3,658 reported vulnerabilities and associated changes, and the authors identified limitations in existing detection and hardening techniques. Those figures do not establish that every bootloader is exploitable or that any particular device is vulnerable. They show why verifying that boot software came from an authorised source is different from establishing that the authorised implementation has no exploitable defect. [36]

Hardware illustrates the limits of single-layer assurance. Application security depends in part on the processor's memory enforcement, its boot chain and the implementation of claimed hardware protections. These dependencies do not make hardware defences pointless; they define the conditions under which software can rely on them.

Containing a failure before it spreads

Security engineering also limits the consequences of a defect that was not prevented. A program handling an unfamiliar file format should not automatically receive the same access to private records, network services and powerful operations as the application that called it. Operating systems can enforce boundaries between running processes and restrict their permissions. A sandbox is a set of such enforced limits. The relevant question is which running component is barred from which resources. Placing files in separate source folders, calling a function through a different programming language or describing a library as isolated does not by itself establish an operating-system boundary. [10]

A native decoder loaded into the main application ordinarily shares that application's process, memory and much of its authority. Moving decoding to a separate process gives the worker a distinct address space. Applying additional, appropriately narrow restrictions to that worker can reduce what a defect or compromise can affect directly. Both versions may sit inside the same outer application sandbox; the additional protection comes from the worker's own boundary and permissions. The arrangement has costs in communication, timeouts and recovery, and the host must still inspect the worker's results. A restricted worker that can request arbitrary privileged file operations from its host may simply recreate the confused-deputy problem across the process boundary.

There is substantial research on how these boundaries succeed or fail in practice. Lefeuvre and colleagues' 2025 SoK analysed 211 research efforts and 61 mainstream compartmentalised systems. It identified persistent difficulties in defining usable isolation policies, translating research into production and evaluating threats involving confused deputies and hardware constraints. A separate process is not proof of effective containment if its permissions are excessive or a privileged host acts on unrestricted requests from it. The relevant engineering task is to define the authority available on both sides of an interface and demonstrate that the enforced boundaries match that design. [37]

Containment illustrates a general principle: prevention and damage limitation have different jobs. Input checks aim to reject a harmful operation before it begins. Memory safety rules stop certain invalid accesses. Sandboxing constrains the resources faulty code can reach. Monitoring and recovery help a service recognise and respond to failures that remain possible. Several protections can reduce the consequences of one mistake, but their independence must be established rather than assumed. A successfully exploited defect may therefore remain confined to a restricted component; it does not automatically grant access to every part of the system. An honest security claim identifies the prohibited effect and the mechanisms that enforce the relevant limits, rather than counting technologies or advertising the word secure. [38]

⚠️ The limits of containment and hardware protection

Some protections appear independent because they have different names and settings, yet depend on the same authority. Application sandboxes, process isolation and mandatory access controls commonly rely on the operating-system kernel to enforce their restrictions. The kernel is the central component that manages programs, memory and permissions. If an attacker gains sufficient control over the kernel, it may be able to change or ignore the rules those protections depend on. Several layers of protection are not necessarily several independent lines of defence. [39]

Hardware-supported mitigations can make kernel compromise harder to achieve. Pointer authentication (PAC) signs and authenticates selected pointers, frustrating some control-flow attacks that rely on corrupting them. On Apple systems supporting Memory Integrity Enforcement (MIE), hardware memory tagging, typed allocation and associated operating-system restrictions obstruct classes of memory-corruption exploitation, including attacks against protected system code. Neither mechanism is an independent authority able to uphold application sandbox policy once an attacker has obtained sufficient control of the kernel. [40]

Some protections operate outside the kernel's ordinary control. On supported Apple systems, the Secure Page Table Monitor (SPTM), working with a trusted execution monitor, constrains selected page-table modifications even when an attacker has obtained kernel write capability. These are narrow, hardware-supported memory and code-integrity restrictions, not continued trust in the kernel's decisions about users, files or network access. Which properties persist depends on the platform and the capabilities of the attacker. [39]

The Secure Enclave is an example of a separate enforcement boundary. On supported Apple devices, it is a security processor with its own secure startup, protected memory and microkernel. It is designed to protect selected secrets even if the main operating-system kernel is compromised. An application can generate a private key for operations handled by the Secure Enclave and request permitted cryptographic work without receiving the key itself. What remains protected depends on the key's access policy and the operations the Enclave is responsible for enforcing, not simply on the presence of the chip. [41] [42]

Other systems use different hardware-enforced boundaries. A Trusted Platform Module (TPM), implemented as a separate device or within a processor, protects selected cryptographic keys and can bind their use to measurements of how the system started; it is not a general-purpose environment for running application code. Arm TrustZone separates secure and normal execution states on supported processors, so designated software and resources can remain inaccessible to the normal operating system when the system is correctly designed. Intel Software Guard Extensions (SGX), on supported processors, isolates selected application code and data in enclaves from privileged software, including the operating-system kernel. Unlike Apple's Secure Enclave, TrustZone and SGX do not require a separate security processor. They also protect different resources and cannot be treated as interchangeable. [43] [44] [45]

Keeping some security authority independent from the main kernel can also help restore platform trust after kernel compromise. A trusted startup or recovery path, anchored beyond that kernel's control, can check authorised firmware and operating-system software before the device returns to service. Protected keys and measurements of the boot process may support those checks. NIST distinguishes roots of trust for detecting unauthorised changes, approving updates and recovering damaged platform firmware. Those elements must be assembled into a working recovery process: a TPM, Secure Enclave, TrustZone environment or SGX enclave does not, by itself, restore a compromised operating system. [35] [38]

Such recovery is possible only within a defined threat model. The recovery firmware, hardware root of trust and source of replacement software must themselves remain trustworthy. Until the compromised kernel is replaced, an attacker may still manipulate requests to secure components, deny service or inspect information before protection or after release, even if some keys or enclave memory remain inaccessible. Recovery cannot reverse information already disclosed. The distinction is between protecting selected state during a compromise and re-establishing trustworthy operation afterwards.

Zinkus, Jois and Green's 2022 SoK examined data confidentiality on mobile devices against powerful extraction adversaries, including ones with physical device access or access to related cloud services. Its scope is wider than protecting a key: information may also be exposed before it is secured, after decryption or through dependent services. That historical analysis does not validate current SPTM or Secure Enclave behaviour. It reinforces the need to state which information remains protected, against which capabilities and where it leaves a trusted boundary. [46]

The limits of kernel-dependent protections

SPTM may preserve selected memory restrictions after kernel compromise, and the Secure Enclave may protect designated keys. Neither restores operating-system trust on its own.

An iPhone may support MIE and PAC, but that does not mean every app running on it uses both protections. Apple deploys MIE automatically across selected system attack surfaces, including the kernel. That coverage does not automatically extend to every third-party app, extension, helper process or library. Two apps on the same supported iPhone may therefore have different protections. MIE combines Apple-designed hardware, secure memory allocators and operating-system controls; it is not simply the general Arm Memory Tagging Extension (MTE).

To use hardware memory tagging in their own apps, developers must enable it for the relevant Xcode targets and confirm that the hardware supports it. Entitlements and runtime settings also matter: a diagnostic mode that reports simulated failures is not the same as enforcing the checks. PAC is a separate mitigation. Compatible hardware alone does not mean that every app binary uses PAC; the relevant code must be built for the appropriate arm64e architecture, and external native libraries need compatible builds. Developers should verify which protections are enabled in the actual release, including its components and dependencies, and test on supported physical devices. A device specification is not proof of the protections operating in a particular app. [47] [48] [49]

An architecture diagram or feature list cannot establish which safeguards are effective in the released product. The relevant evidence is which processes are actually protected, which authority enforces each restriction and what remains protected under the failure conditions being considered.

When safeguards fail

Security restrictions must still hold when a required check or operation fails. If an authorisation service is unavailable, failure to obtain a decision does not establish permission to proceed. If a multi-step change stops halfway, partially updated records may violate the rules that the operation was meant to preserve. The response must be defined for the particular task: reject or defer an unverified action, preserve consistent state and make interrupted work recoverable. Treating an error as approval is a fail-open defect; treating every error as a permanent outage is not an adequate design either. [50]

A compromise does not necessarily stop at the first account or process reached. An attacker may use that foothold to obtain higher permissions, called privilege escalation, or to enter additional systems, called lateral movement. Each further step depends on another usable weakness, credential or trusted relationship; control of one service does not automatically establish control of its neighbours. This is why the authority available at the initial foothold, the separation between systems and the checks on privileged requests determine how far an attack can spread. Containment may interrupt the progression even after the first component has been compromised. [51] [52]

Operational recovery matters when prevention and containment are not enough. An attacker who gains administrative control may change records, erase files or deploy ransomware that makes data unusable. A backup can reduce the harm of destruction or corruption, but it does not undo information already stolen. A backup kept under the same compromised permissions may also be altered or erased by the attacker. Recoverable, appropriately protected copies and exercises that verify restoration therefore matter alongside security patches. Monitoring can detect unusual activity and preserve evidence; incident procedures define who can isolate affected systems, revoke credentials and restore a trustworthy service. These measures are not an admission that secure design has failed. They recognise that protecting a system includes limiting the harm of faults that remain possible and returning legitimate work to a known good state. [38]

When the supply chain undermines security

Even a small application depends on software written, built and maintained by others: operating-system components, libraries, development tools and external services. A reported flaw may matter only if an affected version is present and a relevant operation is exposed, but establishing that can be difficult across dependencies maintained on different schedules. A product name therefore says little about the components and services actually involved in its operation. [53]

A useful comparison is an ingredients list. A manufacturer that cannot identify the ingredients in a product cannot easily determine whether a newly discovered problem applies to that product. Software poses the same difficulty. A software bill of materials, or SBOM, records components and versions to improve that visibility, including dependencies obtained through other dependencies. It helps an organisation answer whether a reported vulnerable library is present, but it is not a certificate of safety. The inventory may be incomplete, the vulnerable code may never be reachable, or a component absent from one release may appear in the next. Inventory becomes useful when it is maintained, connected to what has actually been deployed and followed by a process for assessing and repairing affected systems. [54]

Abu Ishgair and colleagues' 2026 SoK uses the AStRA model to examine the actors, steps, resources and artefacts involved in producing and distributing software. It distinguishes the questions an SBOM can answer from those that require evidence about source changes, build integrity, release authority and delivery. A complete inventory does not establish that a build was trustworthy, and provenance does not establish that the resulting program is free of defects. The evidence must match the particular supply-chain risk being assessed. [55]

Knowing which components are present does not establish that their contents or distribution are trustworthy. An attacker can introduce malicious behaviour into a dependency, source repository, build process or software update so that users receive harmful code as part of an apparently legitimate release. This is a software supply-chain compromise, distinct from discovering an accidental vulnerability in a component. Checking the origin and integrity of a package can help detect unauthorised substitution, but even a correctly signed release may be malicious if the supplier or its build process was compromised. Protecting software delivery therefore also requires controls over who may change code and releases, how build credentials are handled and what evidence connects a delivered artefact to its intended source. An SBOM identifies ingredients; it does not certify that their contents or delivery path are safe. [53]

Software does not travel directly from a programmer's editor to a user's device. Code passes through maintainers, repositories, build tools, automated services, signing keys, release approvers and distribution channels. A reviewer may examine the source yet miss a malicious change introduced during packaging; a tightly controlled builder offers little protection if an intruder can authorise what it builds. Separating and verifying these responsibilities matters because a legitimate-looking release can have been altered at a step invisible to the end user. [56]

The 2024 xz Utils backdoor exposed this problem with unusual clarity. Malicious material was concealed in release archives and arranged to affect certain Linux package builds, potentially undermining remote-login authentication on systems with particular dependencies. The distributed release archive was not simply equivalent to the source a reviewer might inspect in the public repository: the build process determined what ended up in the software. The attack was detected before the affected versions became common in stable Linux distributions, but it showed that an apparently authorised upstream release could carry deliberately introduced malicious functionality into downstream packages. That is why trusting a familiar project or its official download path is not enough on its own. This was a supply-chain compromise, not an accidental programming defect. [57] [58]

Build provenance attempts to connect a delivered executable to the source, tools, settings and service that produced it. Reproducible builds can provide additional evidence when independent parties produce matching results from the same source. Frameworks such as SLSA describe ways to record and verify this history. But a record is only as trustworthy as the systems producing it and the independent expectations against which someone checks it. A compromised source can be built reproducibly; a corrupted build service may produce false assurances; a signed statement that nobody verifies achieves little. Provenance can establish parts of a chain of custody, not whether the underlying software behaves securely. [59] [60]

Release signing and distribution present a separate boundary. A valid digital signature can show that an artefact was signed using a particular key and has not subsequently changed. It cannot establish that the signer was trustworthy, that the key was not stolen or that the signed program is safe. A signed release is evidence of authorisation by a key, not a certificate of harmlessness. HTTPS protects a connection to a download website; it does not guarantee that the website, its publisher account or the download itself has not been compromised. A checksum displayed on that same compromised page offers little independent assurance. Secure update systems therefore also verify the expected publisher, trusted metadata, versions and permitted signing authorities, with protections against rollback to old vulnerable releases. These checks reduce particular attacks without eliminating the need to trust and protect the release process. [61]

The hardware supply chain introduces a related problem that is harder to inspect. A chip may begin as a carefully reviewed design, incorporate circuitry or design components from other suppliers, and pass through manufacturing, testing, packaging, transport and integration. The theoretical design may be sound, yet that does not establish that the silicon shipped to a customer is faithful to it. An adversary with access to relevant stages could in principle change circuitry, insert a hidden hardware Trojan, substitute components or alter associated firmware during manufacture or delivery. These are recognised threats to assess, not evidence that a particular manufacturer or device has been compromised. [62] [63]

A verified blueprint is not a verified chip. Checking normal operation, testing samples, examining production records, using trustworthy suppliers, maintaining custody records and authenticating components can all strengthen hardware assurance. But a rare or deliberately hidden circuit behaviour may escape routine tests, and a device's own identity or attestation mechanism depends on hardware and keys whose origin must also be trusted. Secure boot can verify later software only to the extent that the manufactured starting point of that verification is trustworthy. No single certificate or inspection proves the absence of a malicious modification throughout the chain. [62] [63]

Maintenance and the race to repair

Updates deserve particular attention because they often close defects already understood well enough to be repaired. Once details of a flaw become public, attackers may look for systems that still run the affected version. Some vulnerabilities are already being exploited before a fix becomes available. Delaying updates can therefore leave a system open to methods that no longer require original research by the attacker. The necessary work extends beyond clicking an update button: an organisation must know which computers and services it owns, which versions they run, whether a vendor fix exists, whether an affected function is exposed and whether the change has been deployed successfully. Devices and services that have reached the end of vendor support present a different problem because security fixes may no longer be provided at all. [64]

Update responsibility extends beyond the visible application to operating systems, browsers, routers, plug-ins, server software and firmware. Consumer devices may update automatically, but organisations also operate seldom-used machines, inherited services and third-party systems whose versions are not obvious. These are easy to overlook precisely because they appear to be working. An accurate inventory, a named owner and evidence that an update reached the running system distinguish a patching process from a list of released fixes.

Reporting a vulnerability is not the same as repairing it. An essential part of the response is security triage: finding out whether the affected software is present, whether the vulnerable part can be reached, what an attacker could do with it, and whether anyone is already exploiting it. This establishes how urgent the problem is, who needs to act and what evidence still needs checking. A severity score can help, but it cannot determine the danger to a particular product by itself. A triage decision must be revisited when new facts or software changes emerge. If exploitation is under way, protective action may need to begin before the assessment is complete. [65]

Sometimes no fix exists yet. Even when one is released quickly, it must still be checked against the product, tested to avoid breaking important functions, delivered and verified in the version people actually use. During this window, a known weakness may still be exploitable. Access may need to be restricted, an affected feature disabled, a service isolated or, if necessary, taken offline. These temporary measures must be monitored and reviewed until the defect is repaired. Installing a patch also does not undo an attack that might already have happened. [65]

Attackers may move faster than fixes reach the people who need them. In studies of vulnerabilities actually observed being exploited, Mandiant reported average time-to-exploit figures of 63 days for 2018–2019, 32 days for 2021–2022 and five days for 2023. Its 2026 reporting estimated minus seven days for 2025, meaning first observed exploitation preceded patch availability on average in the studied cases. These are measurements of selected exploited vulnerabilities, not timelines for every flaw or measurements of how quickly customers install updates. Zero-day attacks affect the averages. The acceleration also began before today's generative AI systems. [66] [67] [68]

AI-assisted analysis adds pressure to this already difficult race. A published patch or source-code change may reveal what distinguishes a vulnerable version from its replacement. Automated tools can help compare the versions, develop candidate tests and identify exposed systems, reducing the work needed to pursue a known weakness. Research in 2024 demonstrated that an LLM-based agent could exploit several previously disclosed vulnerabilities under controlled conditions when given their descriptions. In September 2026, Google Threat Intelligence reported increased observed exploitation of previously disclosed high-risk vulnerabilities and identified AI-assisted analysis as a possible contributor, not proof that AI caused every incident. [69] [70]

This capability is not confined to model services whose operators can monitor or restrict requests. Some powerful language models are released with downloadable weights and can be run or modified outside their creators' control; their safeguards can be absent, altered or removed. Public evaluations in 2026 found increasingly capable open-weight models on cybersecurity tasks. That does not make every model an effective attacker, nor does it make every known vulnerability easy to exploit. AI also helps defenders review code, discover defects and prepare responses. What changes is the cost and potential speed of searching for weaknesses, including by actors who do not need to observe a model provider's restrictions. [71] [72]

Publishing a fix does not mean users have received it. Downstream maintainers, distributors and operators may still need to integrate, test, approve and deploy the change. Attackers can seek out installations left behind, while hurried deployment can create new failures. Rapid triage, temporary protection and verified rollout are therefore complementary responsibilities, not competing substitutes.

Secure design matters precisely because that window cannot always be eliminated. Memory-safe code can prevent some kinds of memory error; tight permissions and a separate sandbox can limit what a compromised component can reach; input and resource limits can make other attacks harder. Such protections help before a vulnerability is discovered as well as while a fix is being prepared and tested. The ability to withstand some failures, limit the damage and recover is part of security resilience; a system designed for such conditions is also described as survivable. It is not proof that vulnerable software is safe, and it never replaces the work of fixing and verifying a defect. [38]

Outsourcing does not remove these responsibilities. A supplier may build an application, operate a cloud service, manage workplace devices or maintain a website, while the organisation commissioning the work remains responsible for deciding what level of risk it will accept. Some suppliers are highly capable and disciplined; others spread limited attention across too many clients or provide little evidence of maintenance beyond an initial delivery. The relevant weakness is not the mere presence of an external contractor. It is an arrangement in which nobody can clearly identify the system's dependencies, approve access, discover defects, apply changes, validate releases or respond when something goes wrong. Contracts, service descriptions and badges can help allocate expectations, but observable maintenance and accountable ownership matter more than reassuring language. [2]

Open-source software offers a valuable form of scrutiny because its code can be inspected and challenged beyond the original development team. The familiar argument that many people can examine the code, however, does not establish that enough qualified people are actually doing so, or that reported defects will be resolved promptly. Open-source projects range from well-funded organisations to small teams maintaining widely used components; proprietary software also varies greatly in how it is reviewed and maintained. PHP's October 2026 security release illustrates the distinction. After fixing two critical vulnerabilities, the PHP Foundation described how difficult technical trade-offs, a limited pool of experienced maintainers and its decision-making process had delayed work on one underlying problem. It also acknowledged the role of funded engineers and external researchers in completing the repairs. The faults involved corrupted memory after resource exhaustion and stale internal state across requests, connecting the memory and error-handling mechanisms discussed earlier with the specialist maintenance needed to repair a widely used runtime. The point is not that open source is inherently weaker, or that a closed product is safer. It is that the availability of source code creates an opportunity for scrutiny, while sustained expertise, clear responsibility and effective maintenance turn findings into protection. [73]

Software also needs to be tested against the conditions in which it will be used. A successful demonstration of the main feature says little about what happens when the wrong account requests a record, two operations race, a file is malformed or a privileged helper receives an unexpected command. Security validation checks whether defined requirements hold in the version and configuration actually deployed. It can combine code and dependency review with tests of forbidden and legitimate operations and recovery from failure. Tests cannot prove that no vulnerability exists, and a test result from a developer's computer may not establish the restrictions of a released product. Conversely, the absence of a public audit is not proof that a service is insecure. The credible evidence is specific about what was examined, which version and configuration were used, what was found and what remains uncertain. [2]

How to judge a security warning

News reports often compress several different states into the same alarming vocabulary. A weakness is a defect or unsafe condition that could allow harm under some circumstances. A vulnerability is a weakness that can be used to undermine a security property; an exploit is a method of using it. A claim that a flaw allows remote code execution means that under specified conditions an attacker may cause software to execute code. It does not, by itself, establish that a particular organisation was attacked or that all its data was taken. A confirmed breach is evidence that unauthorised access or another compromising event occurred, although the full extent may remain under investigation. Severity labels, exploit demonstrations and incident findings answer different questions and should not be treated as synonyms.

A public vulnerability identifier, often written as a CVE number, helps different organisations discuss the same reported flaw. It is not a record of every affected installation, nor is it proof of successful exploitation. A severity score estimates characteristics of the flaw using a stated scoring model; operational urgency still depends on the environment and what an attacker can reach. The term zero-day is often used for a flaw being exploited before an effective fix is available or before its defender knows about it, though reporting conventions vary. Its significance lies in the defender's limited opportunity to repair the weakness in advance, not in the mystique of the name. A years-old vulnerability with a published patch can still be an immediate emergency if it is being exploited against exposed machines that were never updated. [74] [75]

The first factor in judging practical seriousness is reachability. An attacker who must already have physical control of a locked machine faces different conditions from one who can send a request to a public service. A flaw in a rarely used optional feature differs from the same flaw in an internet-facing service, although both may require repair. The second factor is authority: the consequences depend on whether the affected code can read public information, access private records, change accounts, run commands or influence an administrator through a delegated service. The third factor is exposure and evidence: the affected version must actually be present, the vulnerable route must be usable under relevant conditions, and reports of active exploitation carry more immediate significance than a theoretical possibility alone. [1]

Remediation is the fourth factor. A vendor may already have issued a fix, a service may have deployed it, or an organisation may still be investigating which systems are affected. A patch can remove the immediate defect without proving that every potentially compromised system has been examined. Where exploitation may have occurred before the fix, investigation, credential changes and restoration of trustworthy state may also be necessary. Credible statements distinguish a vulnerability that was found, an attempted attack that was blocked, unauthorised access that was confirmed and damage that has actually been established. Uncertainty is normal during an incident; unsupported certainty is not a substitute for evidence. [65]

These distinctions also make security claims by suppliers and contractors easier to evaluate. Evidence of a maintained component inventory, clear patch ownership, meaningful release testing, controlled privileged access and a workable incident response process is more informative than a promise of complete security. The same questions apply whether the work is performed by a large technology company, a small development team or an external agency. Organisational size is neither proof of competence nor evidence of neglect. What matters is the ability to identify a problem, explain what it can reach, correct it and establish that the correction is present in the system on which people actually depend. [2]

The bottom line

Software security is difficult because an operation can be technically valid and still occur under the wrong conditions. A password may be accepted from an impostor, a privileged service may act for an unauthorised caller, a check may become stale, hostile data may be interpreted as code, or a memory defect may bypass a rule enforced elsewhere. Dependencies, build processes, firmware and maintenance add further opportunities for a safeguard to be missing or ineffective. Each failure has a different cause, so confidence requires understanding the path from attacker influence to a consequential action.

The most useful security claims are specific. They identify what must remain protected, which attacker capabilities are considered, what the affected component can do, which safeguards operate independently and which evidence comes from testing the released configuration. They also explain how dependencies are monitored, how reported vulnerabilities are triaged, how risk is limited while updates are prepared and how deployment is verified. Developers and operators remain responsible for delivering these protections. People who depend on the software need not become security researchers to ask for credible answers instead of accepting a label, a certificate or a successful demonstration as proof.

Things you should know:

References

Numbered sources are cited in the text. n.d. indicates no stated publication date.

1. National Institute of Standards and Technology (2012). Guide for Conducting Risk Assessments. NIST Special Publication 800-30 Rev. 1. DOI: 10.6028/NIST.SP.800-30r1.
2. National Institute of Standards and Technology (2022). Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST Special Publication 800-218. DOI: 10.6028/NIST.SP.800-218.
3. OWASP Foundation (n.d.). Authentication Cheat Sheet. OWASP Cheat Sheet Series.
4. Cybersecurity and Infrastructure Security Agency and Federal Bureau of Investigation (2025). Product Security Bad Practices: Updated Guidance. CISA/FBI advisory, 17 January 2025.
5. OWASP Foundation (n.d.). Session Management Cheat Sheet. OWASP Cheat Sheet Series.
6. Zhuo, S., Biddle, R., Koh, Y. S., Lottridge, D. and Russello, G. (2023). SoK: Human-centered Phishing Susceptibility. ACM Transactions on Privacy and Security, 26(3), Article 24. DOI: 10.1145/3575797.
7. OWASP Foundation (n.d.). Authorization Cheat Sheet. OWASP Cheat Sheet Series.
8. Hardy, N. (1988). The Confused Deputy (or Why Capabilities Might Have Been Invented). ACM SIGOPS Operating Systems Review, 22(4), pp. 36–38. DOI: 10.1145/54289.871709.
9. OWASP Foundation (n.d.). Authorization Patterns Cheat Sheet. OWASP Cheat Sheet Series.
10. The Chromium Project (n.d.). Sandbox Design. Chromium design documentation.
11. National Institute of Standards and Technology (n.d.). Insider Threat. NIST CSRC Glossary.
12. OWASP Foundation (n.d.). Business Logic Security Cheat Sheet. OWASP Cheat Sheet Series.
13. MITRE (n.d.). CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition. Common Weakness Enumeration.
14. OWASP Foundation (n.d.). Input Validation Cheat Sheet. OWASP Cheat Sheet Series.
15. OWASP Foundation (n.d.). SQL Injection Prevention Cheat Sheet. OWASP Cheat Sheet Series.
16. OWASP Foundation (n.d.). Cross Site Scripting Prevention Cheat Sheet. OWASP Cheat Sheet Series.
17. The Rust Project (n.d.). The Rust Programming Language: References and Borrowing; Unsafe Rust. Rust language documentation.
18. The Swift Project (n.d.). Memory Safety. The Swift Programming Language, Swift.org.
19. Python Software Foundation (n.d.). Extending and Embedding the Python Interpreter. Python 3 documentation.
20. Szekeres, L., Payer, M., Wei, T. and Song, D. (2013). SoK: Eternal War in Memory. IEEE Symposium on Security and Privacy, pp. 48–62. DOI: 10.1109/SP.2013.13.
21. Anderson, R. (1993). Why Cryptosystems Fail. Proceedings of the 1st ACM Conference on Computer and Communications Security, pp. 215–227. DOI: 10.1145/168588.168615.
22. Internet Engineering Task Force (2023). Service Identity in TLS. RFC 9525.
23. Internet Engineering Task Force (2020). JSON Web Token Best Current Practices. RFC 8725.
24. Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. IETF RFC 8446. DOI: 10.17487/RFC8446.
25. Clark, J. and van Oorschot, P. C. (2013). SoK: SSL and HTTPS: Revisiting Past Challenges and Evaluating Certificate Trust Model Enhancements. IEEE Symposium on Security and Privacy. DOI: 10.1109/SP.2013.41.
26. National Institute of Standards and Technology (n.d.). Side Channel. NIST CSRC Glossary.
27. Anderson, R. and Needham, R. (1995). Programming Satan's Computer. In Computer Science Today, pp. 426–440. DOI: 10.1007/BFB0015258.
28. Kim, Y., et al. (2014). Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors. Proceedings of the 41st International Symposium on Computer Architecture, pp. 361–372. DOI: 10.1109/ISCA.2014.6853210.
29. Seaborn, M. and Dullien, T. (2015). Exploiting the DRAM Rowhammer Bug to Gain Kernel Privileges. Google Project Zero research, March 2015.
30. Kocher, P., et al. (2018). Spectre Attacks: Exploiting Speculative Execution. arXiv:1801.01203, security research preprint.
31. Lipp, M., et al. (2018). Meltdown: Reading Kernel Memory from User Space. 27th USENIX Security Symposium.
32. Intel (n.d.). Analysis of Speculative Execution Side Channels. Intel Software Security Guidance.
33. NVIDIA (2018). Security Notice: NVIDIA Tegra RCM Vulnerability. NVIDIA Product Security Notice, 24 April 2018.
34. Temkin, K. and ReSwitched (2018). Fusée Gelée: Boot ROM Vulnerability Disclosure. Research disclosure.
35. National Institute of Standards and Technology (2018). Platform Firmware Resiliency Guidelines. NIST Special Publication 800-193. DOI: 10.6028/NIST.SP.800-193.
36. Glosner, C. and Machiry, A. (2026). SoK: All You Ever Wanted to Know About Bootloader Security but Were Afraid to Ask. IEEE Symposium on Security and Privacy. DOI: 10.1109/SP63933.2026.00163.
37. Lefeuvre, H., Dautenhahn, N., Chisnall, D. and Olivier, P. (2025). SoK: Software Compartmentalization. IEEE Symposium on Security and Privacy. DOI: 10.1109/SP61157.2025.00075.
38. Ross, R., Pillitteri, V., Graubart, R., Bodeau, D. and McQuaid, R. (2021). Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. NIST Special Publication 800-160, Vol. 2 Rev. 1. DOI: 10.6028/NIST.SP.800-160v2r1.
39. Apple (n.d.). Operating System Integrity. Apple Platform Security.
40. Apple Security Research (2025). Memory Integrity Enforcement: A Complete Vision for Memory Safety in Apple Devices. Apple Security Research technical blog.
41. Apple (n.d.). Secure Enclave. Apple Platform Security.
42. Apple Developer (n.d.). Protecting Keys with the Secure Enclave. Apple Developer Documentation, Security.
43. Microsoft (n.d.). Trusted Platform Module (TPM) fundamentals. Microsoft Learn.
44. Arm (n.d.). TrustZone for Cortex-A. Arm Technologies.
45. Intel (n.d.). Intel Software Guard Extensions SDK for Linux OS. Intel Developer Documentation.
46. Zinkus, M., Jois, T. M. and Green, M. (2022). SoK: Cryptographic Confidentiality of Data on Mobile Devices. Proceedings on Privacy Enhancing Technologies, 2022(1), pp. 586–607. DOI: 10.2478/popets-2022-0029.
47. Apple Developer (n.d.). Enabling Enhanced Security for Your App. Apple Developer Documentation, Xcode.
48. Apple Developer (n.d.). Preparing Your App to Work with Pointer Authentication. Apple Developer Documentation, Security.
49. LLVM Project (n.d.). Pointer Authentication. Clang Compiler Documentation.
50. OWASP Foundation (2025). A10: Mishandling of Exceptional Conditions. OWASP Top 10: 2025.
51. MITRE (n.d.). Privilege Escalation (TA0004). MITRE ATT&CK knowledge base.
52. MITRE (n.d.). Lateral Movement (TA0008). MITRE ATT&CK knowledge base.
53. OWASP Foundation (2025). A03: Software Supply Chain Failures. OWASP Top 10: 2025.
54. Cybersecurity and Infrastructure Security Agency and international partners (2026). 2026 Minimum Elements for a Software Bill of Materials (SBOM). Joint government guidance.
55. Abu Ishgair, E., Gomez, J., Melara, M. S., Cárdenas, A. A. and Torres-Arias, S. (2026). SoK: A Defense-Oriented Evaluation of Software Supply Chain Security. IEEE European Symposium on Security and Privacy, pp. 836–859. DOI: 10.1109/EuroSP68448.2026.00059.
56. Boyens, J., et al. (2024). Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. NIST SP 800-161 Rev. 1, Update 1.
57. Arasaratnam, O., et al. (2024). xz Backdoor CVE-2024-3094. Open Source Security Foundation, 30 March 2024.
58. Cox, R. (2024). Timeline of the xz Open Source Attack. Research note, 2024.
59. Supply-chain Levels for Software Artifacts (n.d.). Provenance. SLSA Specification, version 1.2.
60. Supply-chain Levels for Software Artifacts (n.d.). Build: Verifying Artifacts. SLSA Specification, version 1.2.
61. The Update Framework (2024). Overview. TUF Documentation, last updated October 2024.
62. Rekhi, S., Amberiadis, K., Akib, A. A., and Srivastava, A. (2025). Analyzing Collusion Threats in the Semiconductor Supply Chain. NIST Cybersecurity White Paper 46. DOI: 10.6028/NIST.CSWP.46.
63. National Institute of Standards and Technology (n.d.). Supply Chain. NIST Mobile Threat Catalogue.
64. Cybersecurity and Infrastructure Security Agency (n.d.). Known Exploited Vulnerabilities Catalog. CISA vulnerability catalogue.
65. UK National Cyber Security Centre (n.d.). Vulnerability Management: Carry Out Assessments. NCSC vulnerability management guidance.
66. Charrier, C., and Semrau, J. (2023). Analysis of Time-to-Exploit Trends: 2021–2022. Mandiant / Google Threat Intelligence, 28 September 2023.
67. Charrier, C., and Weiner, R. (2024). How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. Mandiant / Google Threat Intelligence, 15 October 2024.
68. Mandiant (2026). M-Trends 2026: Data, Insights, and Strategies From the Frontlines. Google Threat Intelligence.
69. Fang, R., Bindu, R., Gupta, A., and Kang, D. (2024). LLM Agents Can Autonomously Exploit One-Day Vulnerabilities. arXiv preprint 2404.08144.
70. Grunewald, R., Mazumdar, S., and Vanderlee, K. (2026). Vulnerability Discovery and Exploitation Trends in the AI Era. Google Threat Intelligence Group, 1 October 2026.
71. UK AI Security Institute (2026). How Far Behind the Frontier Are Leading Open-Weight Models on Cyber? AISI Work.
72. International AI Safety Report (2026). International AI Safety Report 2026. Section 3.4, Open-weight models.
73. The PHP Foundation (2026). Today's PHP Security Release, and How We're Strengthening PHP Security. The PHP Foundation Blog, 21 October 2026.
74. CVE Program (n.d.). Common Vulnerabilities and Exposures: CVE Program Mission and Records. CVE Program.
75. FIRST (n.d.). Common Vulnerability Scoring System (CVSS) v4.0: User Guide. FIRST.org, document version 1.2.