CSSLP · Secure Software Implementation

Adhere to relevant secure coding practices

Implementation must conform to applicable secure-coding standards, organizational baselines, regulatory obligations, language guidance, and project-specific security requirements.

Example: Follow the approved requirement and applicable coding standard while minimizing attack surface and complexity.

Counterexample: Let each team reinterpret the requirement independently so the implementation remains flexible across services handling the implementation. | Freeze the current coding rule indefinitely even after the language, framework, threat, or governing requirement changes. | Publish the rule in a document but omit training, automated checks, review criteria, and build enforcement.

Limitations: Do not treat a generic “best practice” as superior to an applicable mandatory standard.

Tradeoffs: The best implementation decision is normally the one that satisfies the approved requirement and coding standard while minimizing attack surface and complexity.

Secure coding standards

Coding standards translate recurrent weakness patterns into concrete implementation rules for developers and reviewers. They should be language-, framework-, and risk-context aware.

Example: Standards should be maintainable, testable, version controlled, and linked to review and build gates.

Counterexample: Treat a successful code scan as proof that every legal and organizational obligation affecting the implementation has been implemented. | Issue the rule in a document but omit training, automated checks, review criteria, and build enforcement. | Keep the current coding rule indefinitely even after the language, framework, threat, or governing requirement changes.

Limitations: A standard that is not adopted, trained, checked, and enforced is only documentation.

Tradeoffs: Standards should be maintainable, testable, version controlled, and linked to review and build gates.

Secure coding guidelines

Guidelines provide recommended implementation techniques and examples. They may become mandatory when adopted by policy, contract, or a governing authority.

Example: Use guidelines to clarify safe idioms where strict rules would be impractical.

Counterexample: Retain the current coding rule indefinitely even after the language, framework, threat, or governing requirement changes. | Treat a successful code scan as proof that every legal and organizational obligation affecting the implementation has been implemented. | Allow each team to reinterpret the requirement independently so the implementation remains flexible across services handling the implementation.

Limitations: Guideline does not automatically mean optional in every organizational context.

Tradeoffs: Use guidelines to clarify safe idioms where strict rules would be impractical.

Regulatory implementation constraints

Regulations may impose concrete implementation outcomes such as strong authentication, auditability, data minimization, approved cryptography, or retention enforcement.

Example: Developers implement derived software requirements, legal interpretation belongs to authorized legal and compliance roles.

Counterexample: Keep the existing coding rule indefinitely even after the language, framework, threat, or governing requirement changes. | Follow the developer’s preferred generic practice even when it conflicts with the approved mandatory baseline. | Handle failure around derived authentication, audit, minimization, and cryptographic requirements by continuing with a permissive default and limited audit evidence.

Limitations: Do not infer that passing a code scan proves regulatory compliance.

Tradeoffs: Developers implement derived software requirements, legal interpretation belongs to authorized legal and compliance roles.

Declarative security

Declarative security expresses desired policy or constraints through metadata, configuration, annotations, policy languages, or platform rules rather than custom control-flow code.

Example: Express the common policy in centrally enforced platform metadata, and verify that the runtime mediates every protected path.

Counterexample: Copy the decision logic into every endpoint, allowing policy changes and failure behavior to drift across the protected operation. | Permit the protected operation whenever the policy service is unavailable so availability is never affected. | Consider declaration of the policy as proof that the runtime mediates every path reaching the protected operation.

Limitations: Declarative does not mean self-enforcing, the runtime or policy engine must be trustworthy.

Tradeoffs: Prefer declarative controls when the platform can enforce them consistently and centrally.

Imperative (programmatic) security

Imperative security implements control logic explicitly in code, such as authorization checks, transaction guards, or validation routines.

Example: Implement the context-dependent decision in one reviewed server-side routine rather than copying divergent checks across endpoints.

Counterexample: Allow the protected operation whenever the policy service is unavailable so availability is never affected. | Return a decision without binding it to the subject, object, action, context, or enforcement point. | Replicate the decision logic into every endpoint, allowing policy changes and failure behavior to drift across the protected operation.

Limitations: Duplicated imperative checks can drift and become inconsistent.

Tradeoffs: Use programmatic controls where context-specific logic cannot be represented safely in declarative policy.

Declarative versus imperative trade-off

Declarative mechanisms improve consistency and auditability, imperative mechanisms provide flexibility. Mature implementations frequently combine both.

Example: Combine centrally governed policy with narrowly scoped programmatic checks, defining precedence and blocking alternate bypass paths.

Counterexample: Regard declaration of the policy as proof that the runtime mediates every path reaching the protected operation. | Replicate the decision logic across every endpoint, allowing policy changes and failure behavior to drift across the protected operation. | Issue a decision without binding it to the subject, object, action, context, or enforcement point.

Limitations: Do not present the two approaches as mutually exclusive.

Tradeoffs: The key question is where policy is defined, where it is enforced, and how bypass is prevented.

Policy enforcement point

A policy enforcement point intercepts a request or action and applies an authorization or security decision before the protected operation occurs.

Example: Intercept every route to the protected operation at an authoritative server-side enforcement point before the action executes.

Counterexample: Provide a decision without binding it to the subject, object, action, context, or enforcement point. | Approve the server-side path immediately before a protected operation from documentation alone without automated checks, review criteria, or build enforcement. | Choose the most flexible implementation for the server-side path immediately before a protected operation even though it broadens authority and attack surface.

Limitations: A UI-only check is not a reliable enforcement point.

Tradeoffs: Enforcement must be placed on every meaningful path to the protected resource.

Policy decision point

A policy decision point evaluates policy using subject, object, action, and contextual attributes and returns a decision to an enforcement point.

Example: Evaluate subject, object, action, and context in the decision service, with an explicit secure response when that service is unavailable.

Counterexample: Implement only the visible path for the central authorization decision service and omit alternate interfaces, failure behavior, and authoritative enforcement. | Continue using the check in the user interface and trust callers not to invoke another path to the protected operation. | Copy the implementation for the central authorization decision service across services without a single governed policy or review point.

Limitations: A decision service outage requires an explicit fail-secure strategy.

Tradeoffs: Separate decision and enforcement when doing so improves consistency, testability, and governance.

Concurrency

Concurrent execution creates correctness and security risks when multiple threads, processes, transactions, or distributed workers operate on shared state.

Example: Define the security invariant and make the state transition consistent across concurrent threads, transactions, and workers.

Counterexample: Apply nested locks around every operation without a lock order, timeout, or recovery strategy. | Assume that placing one statement inside a transaction prevents every race regardless of isolation level or external state. | Recheck only before the operation begins even though the validated object can change before commitment.

Limitations: Concurrency bugs are not limited to performance defects.

Tradeoffs: Security-sensitive state transitions must define consistency and synchronization requirements.

Thread safety

Thread-safe code preserves intended invariants when called concurrently. Techniques include immutability, synchronization, atomic operations, thread confinement, and safe concurrent collections.

Example: Use the simplest mechanism that preserves the shared-state invariant without unbounded blocking.

Counterexample: Presume that placing one statement inside a transaction prevents every race regardless of isolation level or external state. | Retry the failed operation without idempotency or duplicate protection, allowing repeated changes to the shared state. | Use broad nested locks around every operation without a lock order, timeout, or recovery strategy.

Limitations: Adding locks indiscriminately can introduce deadlock and denial-of-service risk.

Tradeoffs: Choose the least complex mechanism that preserves the security invariant.

Database concurrency controls

Transactions, isolation levels, uniqueness constraints, conditional updates, and locking help prevent lost updates, duplicate operations, and inconsistent authorization decisions.

Example: Enforce the one-time database invariant with an appropriate isolation level, uniqueness rule, and atomic conditional update.

Counterexample: Check only before the operation begins even though the validated object can change before commitment. | Employ broad nested locks around every operation while omitting a lock order, timeout, or recovery strategy. | Repeat the failed operation while omitting idempotency or duplicate protection, allowing repeated changes to the shared state.

Limitations: A transaction does not automatically prevent all race conditions, isolation level matters.

Tradeoffs: Database-enforced invariants are often stronger than application-only checks.

Race conditions

A race condition occurs when security-relevant behavior depends on unpredictable interleaving between concurrent actors.

Example: Make the check and update atomic, or redesign the workflow so request interleaving cannot violate the security invariant.

Counterexample: Reissue the failed operation while omitting idempotency or duplicate protection, allowing repeated changes to the shared state. | Inspect only before the operation begins even though the validated object can change before commitment. | Check two concurrent requests that update the same security state once and later reopen or use it after the validated state may have changed.

Limitations: Testing alone cannot compensate for an undefined concurrency model.

Tradeoffs: Identify the invariant and make the check-and-update sequence atomic or otherwise concurrency safe.

TOCTOU implementation risk

Time-of-check to time-of-use flaws arise when the checked object or state can change before it is used.

Example: Operate on the already validated handle or revalidate the resolved object at commitment time instead of reopening an unchecked path.

Counterexample: Assume one transaction protects a file checked by path and reopened later from every race regardless of isolation level or external state. | Preserve the ordinary read-then-write sequence and rely on testing to expose rare interleavings affecting the shared state. | Add broad nested locks around every operation without a lock order, timeout, or recovery strategy.

Limitations: Checking a path and later reopening it is weaker than operating on an already validated handle.

Tradeoffs: Revalidate at commitment time or use atomic system calls, transactions, handles, or immutable references.

Deadlock and livelock security impact

Improper synchronization can prevent progress, exhaust worker pools, or make critical controls unavailable.

Example: Use bounded waits, a consistent lock order, and a recovery path so synchronization failure cannot exhaust critical service capacity.

Counterexample: Wrap operations in nested locks around every operation without a lock order, timeout, or recovery strategy. | Rely on the assumption that placing one statement inside a transaction prevents every race regardless of isolation level or external state. | Check locks protecting account state and audit state once and later reopen or use it after the validated state may have changed.

Limitations: Availability is a security property, deadlock can become a denial-of-service vulnerability.

Tradeoffs: Set bounded waits, establish lock ordering, and design recovery paths.

Input validation and sanitization

All data crossing a trust boundary must be validated according to the expected type, syntax, length, range, structure, encoding, and business rules. Sanitization transforms or removes unsafe content where transformation is appropriate.

Example: Validate structure and business rules at the authoritative boundary, and sanitize only when transformation is appropriate.

Counterexample: Maintain a long list of known bad strings as the only acceptance rule. | Remove unexpected characters from every value even when transformation changes valid business data in the request. | Use browser validation because hidden fields and disabled controls prevent callers from changing the request.

Limitations: Validation and sanitization are not synonyms.

Tradeoffs: Validate as early as practical and again at the authoritative use boundary when context changes.

Allowlist validation

Allowlist validation accepts only explicitly permitted forms and is generally preferable for well-defined inputs.

Example: Define canonical permitted forms, reject ambiguous encodings, and enforce business rules separately.

Counterexample: Repeatedly decode input until it looks normal, then authorize the last representation of the request. | Employ browser validation because hidden fields and disabled controls prevent callers from changing the request. | Filter unexpected characters from every value even when transformation changes valid business data in the request.

Limitations: An allowlist that omits business-rule validation remains incomplete.

Tradeoffs: Define canonical forms and reject ambiguous or unexpected encodings.

Denylist limitations

Denylist validation blocks known bad patterns but cannot enumerate all malicious forms and is vulnerable to encoding and parser differences.

Example: Use denylists only as supplemental detection, backed by positive validation and safe context-specific APIs.

Counterexample: Delete unexpected characters from every value even when transformation changes valid business data in the request. | Normalize input through repeated decoding until it looks normal, then authorize the last representation of the request. | Keep a long list of known bad strings as the only acceptance rule.

Limitations: A long denylist does not prove comprehensive input safety.

Tradeoffs: Use denylists as supplemental detection, not the sole validation strategy.

Syntactic validation

Syntactic validation checks whether input conforms to an expected grammar, representation, or data type.

Example: Parse the request with a robust grammar-aware parser, then perform separate semantic and authorization checks.

Counterexample: Screen unexpected characters from every value even when transformation changes valid business data in the request. | Accept the request after schema validation and omit ownership, state, limit, transition, and authorization checks. | Depend on browser validation because hidden fields and disabled controls prevent callers from changing the request.

Limitations: Syntactically valid input can still violate authorization or business rules.

Tradeoffs: Use robust parsers rather than ad hoc string manipulation for structured formats.

Semantic validation

Semantic validation checks whether a validly formed value makes sense in the current business and security context.

Example: After schema validation, verify ownership, account state, limits, and permitted transitions.

Counterexample: Rely on browser validation because hidden fields and disabled controls prevent callers from changing the request. | Keep an extensive list of known bad strings as the only acceptance rule. | Keep decoding input until it looks normal, then authorize the last representation of the request.

Limitations: Schema validation alone is not semantic validation.

Tradeoffs: Examples include ownership, account state, transaction limits, and permitted state transitions.

Canonicalization before validation

Canonicalization converts equivalent representations into a standard form before security decisions, reducing traversal, encoding, and parser-confusion attacks.

Example: Canonicalize once with a trusted routine and authorize the canonical target, avoiding repeated decoding and parser disagreement.

Counterexample: Retain an extensive list of known bad strings as the only acceptance rule. | Block one known bad pattern in multiple encoded representations of the same filesystem path and leave alternate encodings, parser differences, and semantic abuse unaddressed. | Treat browser validation because hidden fields and disabled controls prevent callers from changing the request.

Limitations: Repeated decoding can create double-decoding vulnerabilities.

Tradeoffs: Canonicalize once with a trusted routine and validate the canonical result.

Client-side validation limitations

Client-side checks improve usability but are under attacker control and cannot enforce server-side security.

Example: Repeat every security-relevant validation and authorization decision on the trusted server or processing tier.

Counterexample: Retain decoding input until it looks normal, then authorize the last representation of the request. | Rely on browser validation because hidden fields and disabled controls are assumed to be unchangeable. | Strip unexpected characters from every value even when transformation changes valid business data in the request.

Limitations: Hidden fields and disabled buttons are not access controls.

Tradeoffs: Repeat authoritative validation on the server or trusted processing tier.

Parameterized queries

Parameterized queries separate data from command syntax and are the primary implementation defense against SQL injection.

Example: Bind data values through the database driver and avoid string-built query fragments.

Counterexample: Preserve the compact regular expression without input bounds because short patterns are presumed to have predictable runtime. | Sign the serialized content and continue allowing arbitrary object types or gadget-capable construction in the processing path. | Remove one known traversal or injection substring while leaving alternate encodings and parser interpretations available.

Limitations: Parameterization does not automatically secure dynamic identifiers or unsafe stored procedures.

Tradeoffs: Bind values through the database driver and avoid string-built query fragments.

Command injection prevention

Avoid invoking command interpreters with untrusted strings. Prefer direct APIs, strict argument arrays, allowlists, and least-privileged execution.

Example: Replace the shell invocation with a direct API and fixed argument structure under least privilege, rejecting unapproved operations.

Counterexample: Keep the compact regular expression without input bounds because short patterns are presumed to have predictable runtime. | Escape attacker-controlled text and continue passing the result through a command interpreter or dynamic parser. | Rely on the filename, MIME type, signature flag, or schema because each is supplied before the processing path reaches downstream processing.

Limitations: Escaping shell text is fragile and platform dependent.

Tradeoffs: Remove the shell from the data path whenever possible.

Path traversal prevention

Resolve and canonicalize paths, constrain access to an approved root, use safe identifiers, and avoid accepting raw filesystem paths.

Example: Resolve the target under the approved root and authorize the resolved object rather than filtering path substrings.

Counterexample: Assume the filename, MIME type, signature flag, or schema because each is supplied before the processing path reaches downstream processing. | Delete one known traversal or injection substring while leaving alternate encodings and parser interpretations available. | Digitally sign the serialized content and continue allowing arbitrary object types or gadget-capable construction in the processing path.

Limitations: Removing “../” substrings is not sufficient.

Tradeoffs: Perform the authorization decision on the resolved target.

Deserialization safety

Untrusted serialized objects can trigger unexpected type creation, gadget chains, or state manipulation. Prefer simple data formats, explicit schemas, and restricted types.

Example: Use a simple schema-driven format with restricted types and no gadget-capable object construction for untrusted messages.

Counterexample: Strip one known traversal or injection substring while leaving alternate encodings and parser interpretations available. | Retain the compact regular expression while omitting input bounds because short patterns are presumed to have predictable runtime. | Trust the filename, MIME type, signature flag, or schema because each is supplied before the processing path reaches downstream processing.

Limitations: Signing serialized data protects integrity but does not make dangerous object types safe.

Tradeoffs: Treat deserialization as code-adjacent execution risk.

File upload validation

Validate content, size, type, extension, storage location, filename, and downstream processing. Store outside executable paths and generate server-side names.

Example: Validate content, size, type, extension, and downstream behavior, assign a server-side name, and store the upload outside executable paths.

Counterexample: Canonicalize input through repeated decoding until it looks normal, then authorize the last representation of the request. | Block one known bad pattern in a user-supplied document processed by several converters and leave alternate encodings, parser differences, and semantic abuse unaddressed. | Treat well-formed a user-supplied document processed by several converters as authorized without checking ownership, state, limits, or allowed transitions.

Limitations: MIME type and filename extension are attacker controlled.

Tradeoffs: Use multiple controls because file type indicators can disagree.

XML parser hardening

Disable unnecessary external entities, DTD processing, external resource resolution, and excessive expansion. Use safe parser modes.

Example: Configure the parser to disable external entities, DTDs, external resolution, and excessive expansion before processing untrusted XML.

Counterexample: Rely on the client or an attacker-controlled type indicator to validate an XML import endpoint. | Authenticate the serialized content and continue allowing arbitrary object types or gadget-capable construction in the processing path. | Block one known bad pattern in an XML import endpoint and leave alternate encodings, parser differences, and semantic abuse unaddressed.

Limitations: Input validation alone may not prevent XXE if the parser resolves external entities.

Tradeoffs: Configure the parser explicitly rather than relying on defaults.

Regular-expression denial of service

Backtracking-heavy expressions can cause extreme CPU consumption on crafted input.

Example: Replace the backtracking expression with a bounded or linear-time alternative and cap the accepted input length.

Counterexample: Retain the compact regular expression without input bounds because short patterns are presumed to have predictable runtime. | Quote attacker-controlled text and continue passing the result through a command interpreter or dynamic parser. | Accept the filename, MIME type, signature flag, or schema because each is supplied before the processing path reaches downstream processing.

Limitations: A concise regular expression is not necessarily safe.

Tradeoffs: Use linear-time engines or bounded, reviewed expressions and limit input length.

Error and exception handling

Errors must be handled predictably without exposing sensitive implementation details, bypassing cleanup, corrupting state, or silently ignoring security failures.

Example: Map failures centrally, preserve a secure state, roll back partial work, and expose only a stable minimal error contract.

Counterexample: Return the stack trace, database error, path, account detail, and cryptographic status to help callers diagnose the failure path. | Deploy cleanup only after success, leaving locks, sessions, transactions, temporary data, or keys allocated when an error occurs on the failure path. | Swallow the exception completely, removing the context required for audit, rollback, and correct handling of the failure path.

Limitations: Catching every exception and continuing is not resilience.

Tradeoffs: Use structured exception handling, centralized mapping, and secure default outcomes.

Fail-secure exception behavior

When a security decision cannot be completed, the implementation should preserve the protected state and deny or defer the sensitive operation according to policy.

Example: Deny or defer the sensitive operation while preserving protected state, using a policy-defined degraded path instead of an implicit fail-open.

Counterexample: Implement cleanup only after success, leaving locks, sessions, transactions, temporary data, or keys allocated when an error occurs on the failure path. | Crash the entire service for every minor error even when policy permits a bounded and safe local failure. | Issue the stack trace, database error, path, account detail, and cryptographic status to help callers diagnose the failure path.

Limitations: Fail-secure does not mean crashing the entire service for every minor error.

Tradeoffs: Define failure modes for authorization, key services, and validation dependencies.

Exception propagation

Preserve enough context for correct handling while preventing sensitive internals from crossing trust boundaries.

Example: Translate internal failures into stable external errors while preserving protected diagnostic context internally.

Counterexample: Discard the exception completely, removing the context required for audit, rollback, and correct handling of the failure path. | Provide the stack trace, database error, path, account detail, and cryptographic status to help callers diagnose the failure path. | Terminate the entire service for every minor error even when policy permits a bounded and safe local failure.

Limitations: Swallowing exceptions destroys auditability and can leave partial state.

Tradeoffs: Translate internal errors to stable external error contracts.

Resource cleanup on error

Files, locks, sessions, transactions, temporary data, and cryptographic material must be released or rolled back reliably on all exit paths.

Example: Use guaranteed cleanup constructs so locks, sessions, transactions, temporary data, and key material are released on every exit path.

Counterexample: Stop the entire service for every minor error even when policy permits a bounded and safe local failure. | Ignore the exception completely, removing the context required for audit, rollback, and correct handling of the failure path. | Release resources for a failed key-rotation operation holding locks and temporary files only on the successful path and omit rollback after errors.

Limitations: Cleanup code that runs only on success creates security and availability defects.

Tradeoffs: Use language constructs that guarantee cleanup.

Information leakage through errors

Stack traces, database errors, file paths, account existence, cryptographic details, and internal identifiers can assist attackers.

Example: Return minimal external error detail and record richer diagnostics in protected internal logs.

Counterexample: Stop the entire service for each minor error even when policy permits a bounded and safe local failure. | Catch every failure, continue execution, and preserve partially changed state so the service remains available around the failure path. | Treat a generic best practice as overriding the approved requirement governing an error returned to an unauthenticated caller.

Limitations: Generic external messages must not prevent internal observability.

Tradeoffs: Expose minimal user-facing detail and log richer diagnostic context securely.

Output sanitization

Output must be transformed for the specific destination context so data cannot be interpreted as active code, markup, query syntax, or control sequences.

Example: Encode untrusted data for its actual destination at the final output boundary.

Counterexample: Treat earlier input validation and send the stored value directly to the active output context. | Treat CSP, URL encoding, newline removal, or obfuscation as a replacement for correct sink-specific handling of the output. | Concatenate untrusted data into a framework header, redirect, DOM, log, or template because the value was previously sanitized.

Limitations: Input validation does not replace output encoding.

Tradeoffs: Encode at the final output boundary for the actual sink.

Context-sensitive output encoding

HTML, attribute, JavaScript, CSS, URL, SQL, shell, and log contexts require different encoding or safe APIs.

Example: Use the framework-safe API or encoder for the exact HTML, attribute, script, URL, log, or command context being written.

Counterexample: Regard CSP, URL encoding, newline removal, or obfuscation as a replacement for correct sink-specific handling of the output. | Encode before storage and reuse that representation unchanged across every later destination that consumes the output. | Use earlier input validation and send the stored value directly to the active output context.

Limitations: One universal encoding function is not safe for every context.

Tradeoffs: Use framework-provided auto-escaping and safe templating by default.

Obfuscation as output protection

Obfuscation can reduce casual readability but does not provide cryptographic confidentiality or durable access control.

Example: Use obfuscation only to delay casual analysis or protect intellectual property, retaining real confidentiality and authorization controls.

Counterexample: Approve a client-side rules bundle from documentation alone without automated checks, review criteria, or build enforcement. | Employ earlier input validation and send the stored value directly to the active output context. | Escape before storage and reuse that representation unchanged across every later destination that consumes the output.

Limitations: Obfuscation is not encryption.

Tradeoffs: Use obfuscation only as a supplementary measure with a defined objective.

Cross-site scripting prevention

Use contextual encoding, safe DOM APIs, template auto-escaping, content security policy, and avoidance of unsafe HTML injection.

Example: Render untrusted values through contextual auto-escaping or safe DOM APIs, using CSP only as additional containment.

Counterexample: Transform before storage and reuse that representation unchanged across every later destination that consumes the output. | Approve a comment rendered by a web template from documentation alone without automated checks, review criteria, or build enforcement. | Implement only the visible path for a comment rendered by a web template and omit alternate interfaces, failure behavior, and authoritative enforcement.

Limitations: CSP is defense in depth, not a substitute for correct encoding.

Tradeoffs: Treat stored, reflected, and DOM-based XSS according to the relevant data flow.

HTTP header injection prevention

Reject or safely encode control characters and use framework APIs for response headers, redirects, and cookies.

Example: Use framework header and redirect APIs, rejecting control characters instead of concatenating untrusted input.

Counterexample: Transform before storage and reuse that representation unchanged across each later destination that consumes the output. | Use one universal encoder for every HTML, attribute, script, URL, header, log, and command destination involving the output. | Depend on earlier input validation and send the stored value directly to the active output context.

Limitations: URL encoding alone does not protect every HTTP header context.

Tradeoffs: Do not concatenate untrusted input into protocol headers.

Log injection prevention

Normalize or encode untrusted log fields, preserve record boundaries, and use structured logging.

Example: Write untrusted fields through structured logging with preserved record boundaries and format-appropriate normalization.

Counterexample: Rely on earlier input validation and send the stored value directly to the active output context. | Treat well-formed a username written to structured audit records as authorized without checking ownership, state, limits, or allowed transitions. | Block one known bad pattern in a username written to structured audit records and leave alternate encodings, parser differences, and semantic abuse unaddressed.

Limitations: Removing newline characters alone may not prevent parser confusion in every log format.

Tradeoffs: Treat logs as a security-sensitive output sink.

Secure logging and auditing

Implementation must generate useful, accurate, tamper-resistant events without exposing secrets or unnecessary personal data.

Example: Emit stable security events for important decisions while minimizing secrets and unnecessary personal data.

Counterexample: Adopt verbose production debug logs as the audit trail even though schemas, access, purpose, and retention differ. | Collect unlimited personal information because an audit requirement is assumed to override minimization and retention. | Retain a checksum beside a mutable local log and allow the application to edit both the event and its integrity value.

Limitations: More logging is not always better, excessive logging can create confidentiality and availability risk.

Tradeoffs: Log security-relevant decisions and outcomes with stable event schemas.

Logging confidentiality

Logs must not expose passwords, private keys, session tokens, full payment data, or unnecessary sensitive payloads.

Example: Redact or tokenize secrets and sensitive payment fields before logging, then restrict access to the remaining audit data.

Counterexample: Retain only successful events and omit denials, failures, target identity, synchronized time, and correlation data. | Keep a checksum beside a mutable local log and allow the application to edit both the event and its integrity value. | Gather unlimited personal information because an audit requirement is assumed to override minimization and retention.

Limitations: Hashing a low-entropy secret may still permit recovery.

Tradeoffs: Apply redaction, tokenization, field selection, and access controls.

Logging privacy

Collect only necessary personal data, apply purpose limitation and retention, and restrict access to audit data.

Example: Include only personal data necessary for the audit purpose, with defined access, retention, and deletion controls.

Counterexample: Retain unlimited personal information because an audit requirement is assumed to override minimization and retention. | Record only successful events and omit denials, failures, target identity, synchronized time, and correlation data. | Choose verbose production debug logs as the audit trail even though schemas, access, purpose, and retention differ.

Limitations: Audit requirements do not justify unlimited personal-data collection.

Tradeoffs: Design privacy controls into the event schema, not as an afterthought.

Security event completeness

Useful audit events identify actor, action, target, time, result, relevant context, and correlation identifiers.

Example: Record successful and failed high-risk actions with actor, target, time, result, context, and correlation data.

Counterexample: Copy the implementation for an administrative privilege change across services without a single governed policy or review point. | Capture complete passwords, tokens, payment values, personal payloads, and debug context so no detail about the audit record is lost. | Place a checksum beside a mutable local log and allow the application to edit both the event and its integrity value.

Limitations: Logs without synchronized time or stable identifiers may be unusable for investigations.

Tradeoffs: Record both successful and failed high-risk actions.

Log integrity and provenance

Protect event ordering, origin, and content using access control, append-only storage, forwarding, signatures or hashes where justified.

Example: Forward events to protected append-only storage and separate the application’s write permission from any ability to alter history.

Counterexample: Use unsynchronized timestamps and unstable identifiers in centrally collected audit records, making cross-service events difficult to correlate. | Apply verbose production debug logs as the audit trail even though schemas, access, purpose, and retention differ. | Document only successful events and omit denials, failures, target identity, synchronized time, and correlation data.

Limitations: A checksum stored beside a mutable log does not independently prove integrity.

Tradeoffs: Separate the application’s ability to write events from its ability to alter historical records.

Audit versus debug logging

Audit logs support accountability and investigations, debug logs support diagnosis and often contain more implementation detail.

Example: Separate audit and debug schemas, access, retention, and production settings so diagnostic detail cannot replace accountable event records.

Counterexample: Use verbose production debug logs as the audit trail even though schemas, access, purpose, and retention differ. | Use unsynchronized timestamps and unstable identifiers in production audit and diagnostic events, making cross-service events difficult to correlate. | Store a checksum beside a mutable local log and allow the application to edit both the event and its integrity value.

Limitations: Enabling verbose debug logs in production can leak sensitive data.

Tradeoffs: Use separate schemas, access controls, and production policies.

Session management

Sessions bind authenticated identity and authorization context to subsequent requests. Session identifiers must be unpredictable, confidential, scoped, rotated, expired, and revocable.

Example: Use the framework session mechanism with unpredictable identifiers, rotation, expiry, revocation, and reauthentication after trust changes.

Counterexample: Rely on a long absolute lifetime without revocation because repeated authentication would reduce usability. | Retain the same identifier through login and privilege elevation because authentication already established trust in the session. | Regard HttpOnly, SameSite, CORS, or an origin header as a complete session and request-forgery defense.

Limitations: Authentication success does not make the entire future session trustworthy.

Tradeoffs: Use established framework session mechanisms instead of custom token formats.

Session identifier entropy

Session identifiers require sufficient unpredictability and uniqueness to resist guessing and collision.

Example: Generate session identifiers with a cryptographically secure platform mechanism rather than encoding predictable user or time values.

Counterexample: Treat HttpOnly, SameSite, CORS, or an origin header as a complete session and request-forgery defense. | Adopt a long absolute lifetime without revocation because repeated authentication would reduce usability. | Erase the browser cookie on logout while leaving server-side state or self-contained token authority valid.

Limitations: Encoding a user ID or timestamp does not create secure randomness.

Tradeoffs: Use a cryptographically secure generator or established platform mechanism.

Session fixation prevention

Issue a new session identifier after authentication and other privilege changes so an attacker cannot predetermine the victim’s authenticated session.

Example: Issue a new server-side session identifier immediately after login, elevation, recovery, and other privilege transitions.

Counterexample: Keep an identifier established before login valid through authentication and privilege changes without rotating the server-side session identifier. | Derive the session identifier from the user, time, or account and protect it only with TLS. | Keep the same identifier through login and privilege elevation because authentication already established trust in the session.

Limitations: TLS does not prevent fixation if the identifier was attacker chosen.

Tradeoffs: Rotate on login, elevation, account recovery, and other trust transitions.

Session expiration

Use idle timeout, absolute lifetime, and event-driven revocation based on risk and business needs.

Example: Enforce idle and absolute lifetimes plus event-driven server-side revocation, shortening or reauthenticating high-risk sessions.

Counterexample: Preserve the same identifier through login and privilege elevation because authentication already established trust in the session. | Clear the browser cookie on logout while leaving server-side state or self-contained token authority valid. | Use a long absolute lifetime without revocation because repeated authentication would reduce usability.

Limitations: Client-side deletion alone does not invalidate a server session.

Tradeoffs: High-risk sessions generally require shorter lifetimes and reauthentication.

Cookie security attributes

Use Secure, HttpOnly, SameSite, narrow Path and Domain scope, and appropriate prefixes for session cookies.

Example: Set Secure, HttpOnly, SameSite, and narrow path and domain scope, while retaining independent CSRF and session controls.

Counterexample: Close the browser cookie on logout while leaving server-side state or self-contained token authority valid. | Treat Secure, HttpOnly, SameSite, CORS, or origin checks as a complete defense. | Assume TLS prevents fixation or misuse of the browser session cookie after an attacker has influenced the identifier.

Limitations: HttpOnly prevents script access but does not stop all CSRF or session misuse.

Tradeoffs: Cookie attributes are defense in depth around a sound session design.

Logout and revocation

Logout should invalidate server-side session state or otherwise revoke tokens, not merely remove a browser cookie.

Example: Invalidate server-side state or revoke the token on logout and compromise rather than deleting only the browser cookie.

Counterexample: Employ a long absolute lifetime while omitting revocation because repeated authentication would reduce usability. | Give server-side state after browser logout a long lifetime without revocation, event-driven invalidation, or risk-based reauthentication. | Assume HttpOnly, SameSite, CORS, or an origin header as a complete session and request-forgery defense.

Limitations: Self-contained tokens require an explicit revocation or short-lifetime strategy.

Tradeoffs: Support revocation for compromise, role changes, and administrator action.

CSRF defenses

Protect state-changing browser requests using anti-CSRF tokens, SameSite cookies, origin checks, reauthentication, and safe HTTP method semantics.

Example: Use anti-CSRF controls suited to the authentication mechanism, including tokens, SameSite, origin checks, or reauthentication.

Counterexample: View HttpOnly, SameSite, CORS, or an origin header as a complete session and request-forgery defense. | Apply a long absolute lifetime without revocation because repeated authentication would reduce usability. | Assume TLS prevents fixation or misuse of a state-changing browser request after an attacker has influenced the identifier.

Limitations: CORS is not a CSRF defense.

Tradeoffs: Choose controls appropriate to the authentication mechanism and client type.

Trusted and untrusted APIs

APIs and libraries must be classified by trust, provenance, privilege, input assumptions, update model, and failure behavior.

Example: Evaluate provenance, privilege, assumptions, updates, and failure behavior, wrapping or isolating functions that cannot be trusted fully.

Counterexample: Ignore thread safety, memory ownership, initialization, encoding, and error preconditions because the library has a strong reputation. | Accept the API or library because it is internal, popular, signed, or maintained by another team, and grant it full process authority over the API or library boundary. | Validate the request schema and authenticated identity but omit object and function authorization at the server boundary.

Limitations: Internal APIs are not automatically trusted.

Tradeoffs: Wrap or isolate untrusted functionality and minimize the authority granted to it.

API contract enforcement

Implement explicit schemas, authentication, authorization, rate limits, error contracts, and versioning at API boundaries.

Example: Enforce schemas, authentication, object and function authorization, rate limits, versions, and stable errors at the server boundary.

Counterexample: Implement only the visible path for a partner API receiving object identifiers and omit alternate interfaces, failure behavior, and authoritative enforcement. | Hide the route or unsafe primitive from normal documentation and treat obscurity as sufficient protection. | Wrap the dangerous or deprecated function without changing its assumptions, failure behavior, or underlying authority over the API or library boundary.

Limitations: Schema validation does not replace authorization.

Tradeoffs: Enforce object- and function-level authorization server side.

Library preconditions and postconditions

Understand what a library assumes about input, thread safety, memory ownership, encoding, initialization, and error handling.

Example: Verify the library’s input, thread-safety, ownership, encoding, initialization, and error assumptions before using it in the privileged path.

Counterexample: Conceal the route or unsafe primitive from normal documentation and treat obscurity as sufficient protection. | Disregard thread safety, memory ownership, initialization, encoding, and error preconditions because the library has a strong reputation. | Implement only the visible path for a parsing library with thread-safety and ownership assumptions and omit alternate interfaces, failure behavior, and authoritative enforcement.

Limitations: A secure library can be integrated insecurely.

Tradeoffs: Security depends on correct use, not only library reputation.

Unsafe or deprecated API avoidance

Avoid functions and modes known to cause buffer, format-string, injection, cryptographic, or memory-safety weaknesses.

Example: Replace the deprecated primitive with a safer abstraction and enforce the ban through reviewed tooling rather than relying on a cosmetic wrapper.

Counterexample: Implement only the visible path for a legacy buffer-copy function and omit alternate interfaces, failure behavior, and authoritative enforcement. | Approve a legacy buffer-copy function from documentation alone without automated checks, review criteria, or build enforcement. | Copy the implementation for a legacy buffer-copy function across services without a single governed policy or review point.

Limitations: A wrapper around a dangerous API does not automatically make it safe.

Tradeoffs: Prefer safer abstractions and enforce bans through tooling where practical.

Resource management

Applications must bound and correctly release compute, storage, network, file, handle, thread, connection, and memory resources.

Example: Set quotas, timeouts, cancellation, and guaranteed cleanup for compute, storage, network, handles, threads, connections, and memory.

Counterexample: Consider validly formed input has acceptable computational cost and omit complexity, amplification, and decompression limits. | Release resources only on successful completion and allow failed requests to retain connections, files, locks, or temporary data. | Rely on disk or transport encryption to prevent exhaustion of compute, storage, memory, handles, or network capacity.

Limitations: Resource exhaustion is a security problem, not only a performance problem.

Tradeoffs: Design quotas and cleanup for both normal and adversarial workloads.

Compute resource controls

Bound expensive operations, request complexity, background jobs, and algorithmic cost.

Example: Apply per-request budgets, bounded complexity, cancellation, and admission control because one request can exceed a simple rate limit.

Counterexample: Regard validly formed input has acceptable computational cost and omit complexity, amplification, and decompression limits. | Apply only a request-per-second limit and leave a single expensive operation unbounded. | Expand pools, queues, retries, and worker counts without admission control, backpressure, cancellation, or dependency budgets.

Limitations: Rate limiting alone may not prevent a single expensive request.

Tradeoffs: Apply timeouts, budgets, cancellation, and admission control.

Storage resource controls

Use quotas, size limits, retention, compaction, and cleanup for uploads, logs, caches, and temporary data.

Example: Set size and tenant quotas, retention, compaction, and cleanup while accounting for duplicate and amplified storage.

Counterexample: Increase pools, queues, retries, and worker counts without admission control, backpressure, cancellation, or dependency budgets. | Depend on disk or transport encryption to prevent exhaustion of compute, storage, memory, handles, or network capacity. | Ship resources only on successful completion and allow failed requests to retain connections, files, locks, or temporary data.

Limitations: Disk encryption does not prevent storage exhaustion.

Tradeoffs: Account for amplification and duplicate storage.

Network resource controls

Limit connections, payload size, bandwidth, retries, fan-out, and queue depth.

Example: Use bounded connections, payloads, retries, fan-out, queues, backpressure, and circuit breakers.

Counterexample: Release resources for retries and fan-out to a failing dependency only on the successful path and omit rollback after errors. | Assume syntactically valid input cannot trigger worst-case processing in retries and fan-out to a failing dependency. | Grow pools, queues, retries, and worker counts without admission control, backpressure, cancellation, or dependency budgets.

Limitations: Unlimited retries can turn a dependency failure into self-denial-of-service.

Tradeoffs: Use backpressure and circuit breakers to prevent cascading failure.

Memory management

Use memory-safe languages or safe subsets where practical, initialize memory, validate lengths, avoid use-after-free, and clear sensitive buffers where meaningful.

Example: Prefer memory-safe implementation or a safe subset, validate lengths, initialize ownership, and use a reliable primitive for clearing sensitive buffers.

Counterexample: Deploy resources only on successful completion and allow failed requests to retain connections, files, locks, or temporary data. | Grow pools, queues, retries, and worker counts while omitting admission control, backpressure, cancellation, or dependency budgets. | Assume validly formed input has acceptable computational cost and omit complexity, amplification, and decompression limits.

Limitations: Manual zeroization may be optimized away unless supported by a reliable primitive.

Tradeoffs: Select implementation strategies according to threat and platform constraints.

Connection pool safety

Pools require bounded size, timeout, health checks, reset of security context, and safe credential handling.

Example: Bound the pool, time out acquisition, health-check connections, and reset transaction, identity, and authorization state before reuse.

Counterexample: Treat validly formed input has acceptable computational cost and omit complexity, amplification, and decompression limits. | Ship resources solely on successful completion and allow failed requests to retain connections, files, locks, or temporary data. | Assume syntactically valid input cannot trigger worst-case processing in a reused database connection.

Limitations: Larger pools can increase cascading failure.

Tradeoffs: Ensure a reused connection does not retain the previous user’s transaction or authorization state.

Algorithmic complexity attacks

Attackers may exploit worst-case parsing, sorting, hashing, decompression, or graph behavior to consume resources.

Example: Limit input and decompression size, select complexity-aware algorithms, and enforce workload budgets even for syntactically valid data.

Counterexample: Presume validly formed input has acceptable computational cost and omit complexity, amplification, and decompression limits. | Use only a request-per-second limit and leave a single expensive operation unbounded. | Raise pools, queues, retries, and worker counts without admission control, backpressure, cancellation, or dependency budgets.

Limitations: Valid input can still be computationally malicious.

Tradeoffs: Use bounded input, complexity-aware algorithms, and workload budgets.

Secure configuration management

Implementation must externalize and control security-relevant settings, establish secure defaults, validate configuration, and prevent unauthorized changes.

Example: Externalize and protect security settings, apply safe defaults, validate changes, and treat configuration as reviewed code and a trust boundary.

Counterexample: Keep the credential in source, a private repository, or a long-lived environment variable because access is restricted. | Silently replace invalid high-risk configuration with a permissive default so startup of the security configuration is not interrupted. | Remove the feature in the user interface while leaving the backend path and emergency bypass flag reachable.

Limitations: A secure binary can be defeated by insecure configuration.

Tradeoffs: Treat configuration as code and as a security boundary.

Baseline security configuration

A baseline defines approved defaults for ports, protocols, privileges, logging, cryptography, and feature enablement.

Example: Apply the approved baseline through automated validation and narrow documented exceptions, adapting it to the service threat and operating context.

Counterexample: Copy a generic baseline for ports, protocols, privileges, logging, and cryptographic defaults without adapting it to the service threat and operating context. | Copy the organization baseline without adapting ports, protocols, privileges, cryptography, logging, or exceptions to the service context. | Store the credential in source, a private repository, or a long-lived environment variable because access is restricted.

Limitations: A baseline must be adapted to context rather than copied blindly.

Tradeoffs: Use automated validation and controlled exceptions.

Credentials management

Credentials must not be hard-coded or stored in source control. Use managed secret stores, short-lived identities, rotation, and least privilege.

Example: Use a managed secret service or workload identity with short lifetimes, rotation, and least privilege instead of embedding credentials in code or CI.

Counterexample: Delete the feature in the user interface while leaving the backend path and emergency bypass flag reachable. | Allow unaudited users to change a service credential used by build and runtime jobs outside version control and approval. | Replicate the organization baseline without adapting ports, protocols, privileges, cryptography, logging, or exceptions to the service context.

Limitations: Environment variables can still leak through process inspection, crash dumps, or diagnostics.

Tradeoffs: Prefer workload identity over static shared secrets where available.

Secrets in source code

Repositories, history, build logs, packages, and generated artifacts can retain exposed secrets even after deletion.

Example: Revoke and rotate the exposed secret, remove it from current files and history, and inspect builds, logs, and artifacts for copies.

Counterexample: Duplicate the organization baseline without adapting ports, protocols, privileges, cryptography, logging, or exceptions to the service context. | Turn off the feature in the user interface while leaving the backend path and emergency bypass flag reachable. | Silently replace an invalid high-risk setting for a token committed to repository history with a permissive default.

Limitations: A private repository is not a secret manager.

Tradeoffs: Revoke and rotate exposed secrets, removing the text is insufficient.

Secure defaults

New installations and features should begin in the least permissive safe state consistent with required functionality.

Example: Ship the feature in the least-permissive useful state and require an explicit authorized action to enable higher-risk capability.

Counterexample: Copy a generic baseline for a newly installed administrative feature without adapting it to the service threat and operating context. | Ship permissive settings and depend on deployment documentation to harden the security configuration after installation. | Retain the credential in source, a private repository, or a long-lived environment variable because access is restricted.

Limitations: Documentation that tells operators to harden insecure defaults is not secure by default.

Tradeoffs: Require explicit action to enable risky capabilities.

Configuration validation

Validate types, ranges, combinations, paths, certificates, and security invariants at startup and change time.

Example: Validate types, ranges, combinations, paths, certificates, and invariants at startup and change time, failing clearly on unsafe settings.

Counterexample: Treat well-formed a startup policy file with inconsistent settings as authorized without checking ownership, state, limits, or allowed transitions. | Use a lengthy list of known bad strings as the only acceptance rule. | Decode input repeatedly until it looks normal, and make the security decision on whichever decoded form remains.

Limitations: Silently substituting permissive defaults can create vulnerabilities.

Tradeoffs: Fail clearly and safely on invalid high-risk configuration.

Feature flags and security

Feature flags must have access control, auditability, safe defaults, expiration, and testing for both states.

Example: Protect the flag with access control, audit, safe defaults, expiry, and tests for both states, including direct backend reachability.

Counterexample: Ship an emergency authorization-bypass flag with permissive defaults and rely on operators to harden it after deployment. | Silently replace an invalid high-risk setting for an emergency authorization-bypass flag with a permissive default. | Allow unaudited users to change an emergency authorization-bypass flag outside version control and approval.

Limitations: A disabled UI flag may leave the backend feature reachable.

Tradeoffs: Treat emergency bypass flags as privileged controls.

Tokenization

Tokenization substitutes a sensitive value with a surrogate token and stores or derives the mapping under controlled conditions.

Example: Replace the sensitive value with a scoped surrogate and protect the mapping or cryptographic method, without treating the result as anonymous.

Counterexample: Preserve the complete original format and structure even when those details increase inference, collision, or attack utility. | Ignore the vault or key boundary because the token appears random and the original value is not stored in the application. | Design a custom reversible scheme instead of using a reviewed mapping or cryptographic construction with controlled keys and context.

Limitations: Tokenization is not the same as encryption or anonymization.

Tradeoffs: Use tokenization to reduce exposure and scope while preserving business workflows.

Vault-based tokenization

A token vault stores the mapping between token and original value and becomes a high-value trust boundary.

Example: Treat the token vault as a high-value boundary with strict access, audit, backup, availability, and segregation controls.

Counterexample: Treat a generic best practice as overriding the approved requirement governing the payment-token mapping service. | Retain the complete original format and structure even when those details increase inference, collision, or attack utility. | Reuse the same token across purposes, tenants, merchants, and systems so downstream correlation remains convenient.

Limitations: Random-looking tokens do not eliminate the sensitivity of the vault.

Tradeoffs: Protect vault access, availability, audit, backup, and segregation.

Vaultless tokenization

Vaultless approaches derive reversible tokens cryptographically and shift risk toward key management, domain separation, and collision handling.

Example: Use a reviewed cryptographic token design with protected keys, domain separation, and collision handling rather than a custom reversible format.

Counterexample: Choose the most flexible implementation for reversible format-preserving payment tokens even though it broadens authority and attack surface. | Consider the surrogate as anonymous and remove personal-data, access, retention, and linkage controls from workflows using the tokenized value. | Disregard the vault or key boundary because the token appears random and the original value is not stored in the application.

Limitations: Vaultless does not mean keyless.

Tradeoffs: Use reviewed, standards-aligned designs rather than custom format-preserving schemes.

Token scope and format

Tokens should be scoped to purpose, system, tenant, or merchant where feasible to reduce cross-context reuse and correlation.

Example: Scope tokens to purpose, tenant, system, or merchant and avoid preserving unnecessary structure that enables linkage or reuse.

Counterexample: Omit the vault or key boundary because the token appears random and the original value is not stored in the application. | Continue using the same token across purposes, tenants, merchants, and systems so downstream correlation remains convenient. | Approve tokens reused across merchants and tenants from documentation alone without automated checks, review criteria, or build enforcement.

Limitations: Preserving the full original format can leak structure and increase attack utility.

Tradeoffs: Design tokens to prevent unintended linkage.

Isolation

Isolation limits the authority and blast radius of code, tenants, processes, and components by separating resources and trust domains.

Example: Enforce separation through a trustworthy lower layer and reduce authority, shared resources, and blast radius across the boundary.

Counterexample: Treat a container as equivalent to a hardware-virtualized guest and ignore the shared kernel and orchestration plane. | Assume the lower-layer boundary cannot be escaped and omit least privilege, quotas, updates, monitoring, and recovery controls. | Operate the untrusted function as root with broad filesystem and network access because a container or sandbox already exists.

Limitations: Logical naming conventions alone are not isolation.

Tradeoffs: Isolation must be enforced by a trustworthy lower layer.

Sandboxing

Sandboxing restricts code through process, system-call, filesystem, network, capability, or language-runtime controls.

Example: Combine sandbox restrictions with least privilege and resource quotas.

Counterexample: Place all privileged and unprivileged functions in one process so communication and deployment remain simple around the isolated workload. | Ignore management-plane, shared-kernel, storage, key, cache, queue, and log paths affecting untrusted document-conversion code. | Consider the lower-layer boundary cannot be escaped and omit least privilege, quotas, updates, monitoring, and recovery controls.

Limitations: A sandbox escape remains possible, sandboxing is defense in depth.

Tradeoffs: Combine sandboxing with least privilege and resource quotas.

Virtualization

Virtual machines isolate guest environments through a hypervisor and virtualized hardware boundary.

Example: Harden the hypervisor, guest images, management plane, device interfaces, shared storage, and credentials.

Counterexample: Treat the presence of a container, VM, or sandbox as sufficient protection for two guest workloads on a shared hypervisor without least privilege or shared-layer controls. | Put all privileged and unprivileged functions in one process so communication and deployment remain simple around the isolated workload. | Regard a container as equivalent to a hardware-virtualized guest and ignore the shared kernel and orchestration plane.

Limitations: VM separation does not automatically secure shared storage or management credentials.

Tradeoffs: Harden the hypervisor, images, management plane, and device interfaces.

Containerization

Containers isolate processes using operating-system namespaces, cgroups, capabilities, and related controls while sharing a kernel.

Example: Use minimal non-root images, read-only filesystems, capabilities, seccomp, quotas, and orchestration policy while accounting for the shared kernel.

Counterexample: Place privileged and unprivileged functions for multi-tenant workloads sharing a host kernel in one monolithic process. | Rely on naming, an internal network, or a tenant identifier supplied by the client as the enforcement boundary. | Execute the untrusted function as root with broad filesystem and network access because a container or sandbox already exists.

Limitations: A container is not equivalent to a virtual machine security boundary.

Tradeoffs: Use minimal images, non-root execution, read-only filesystems, seccomp, and strong orchestration policy.

Separation Kernel Protection Profiles

Separation-kernel profiles specify high-assurance partitioning and controlled information flow for strongly isolated workloads.

Example: Use the approved separation-kernel profile only for the justified high-assurance partitioning and controlled-flow requirement.

Counterexample: Run the untrusted function as root with broad filesystem and network access because a container or sandbox already exists. | Run high-assurance partitions with controlled information flow with the host process’s full authority because logical naming separates the workload. | Use a client-supplied tenant identifier as the authorization basis for high-assurance partitions with controlled information flow.

Limitations: The term should not be reduced to ordinary container isolation.

Tradeoffs: Use only where assurance needs justify the cost and platform constraints.

Process privilege separation

Split privileged and unprivileged functions so most code executes with minimal authority and communicates through narrow interfaces.

Example: Split parsing from privileged operations so most code runs with minimal authority through a narrow authenticated interface.

Counterexample: Ignore management-plane, shared-kernel, storage, key, cache, queue, and log paths affecting a daemon that parses untrusted input and performs privileged writes. | Place privileged and unprivileged functions for a daemon that parses untrusted input and performs privileged writes in one monolithic process. | Deploy the untrusted function as root with broad filesystem and network access because a container or sandbox already exists.

Limitations: A single monolithic privileged process expands impact of every defect.

Tradeoffs: Keep the trusted computing base small.

Tenant isolation

Multi-tenant implementations must isolate identity, data, keys, caches, queues, logs, quotas, and administrative actions.

Example: Bind tenant identity into every authoritative query and isolate tenant data, keys, caches, queues, logs, quotas, and administration.

Counterexample: Position all privileged and unprivileged functions in one process so communication and deployment remain simple around the isolated workload. | Implement the untrusted function as root with broad filesystem and network access because a container or sandbox already exists. | Use a client-supplied tenant identifier as the authorization basis for tenant data, keys, caches, queues, and logs.

Limitations: A tenant ID supplied by the client is not sufficient authorization.

Tradeoffs: Include tenant context in every authoritative access path.

Cryptography

Cryptographic controls must use approved algorithms, modes, parameters, libraries, key lifecycles, and threat-appropriate placement.

Example: Use approved cryptographic libraries and protocols rather than designing custom cryptography.

Counterexample: Keep using nonces or derived keys across purposes because neither value is intended to be secret. | Disable certificate verification or expose distinct padding, signature, and tag errors to simplify troubleshooting of the cryptographic workflow. | Apply encryption without authenticated integrity, replay handling, endpoint authorization, or protected key lifecycle.

Limitations: Correct algorithm names do not guarantee correct implementation.

Tradeoffs: Use established libraries and protocols, do not design custom cryptography.

Payload encryption

Payload encryption protects message content independently of some transport layers and can preserve confidentiality through intermediaries.

Example: Encrypt and authenticate the message payload for the intended recipients, defining decryptors, replay handling, and exposed metadata.

Counterexample: Reuse nonces or derived keys across purposes because neither value is intended to be secret. | Implement a custom algorithm or protocol because the team can improve workflow-specific performance. | Prefer the longest available key and ignore approved profiles, modes, nonces, integrity, interoperability, and platform constraints.

Limitations: Encrypting only the payload may leave metadata exposed.

Tradeoffs: Define which components can decrypt and how integrity and replay are handled.

Field-level encryption

Field-level encryption protects selected sensitive elements within a record or message.

Example: Encrypt only the required fields while designing key separation, rotation, search, indexing, validation, and correlation behavior.

Counterexample: Select the longest available key and ignore approved profiles, modes, nonces, integrity, interoperability, and platform constraints. | Protect the data with encryption without authenticated integrity, replay handling, endpoint authorization, or protected key lifecycle. | Remove certificate verification or expose distinct padding, signature, and tag errors to simplify troubleshooting of the cryptographic workflow.

Limitations: Field encryption can break validation or create deterministic correlation risk.

Tradeoffs: Plan indexing, searching, key separation, rotation, and access patterns.

Transport encryption

Transport protection secures data over a connection using authenticated protocols such as TLS.

Example: Use current authenticated TLS settings and verify peer identity, recognizing that protection ends at the connection endpoints.

Counterexample: Harden the data with encryption while omitting authenticated integrity, replay handling, endpoint authorization, or protected key lifecycle. | Retain using nonces or derived keys across purposes because neither value is intended to be secret. | Choose the longest available key and ignore approved profiles, modes, nonces, integrity, interoperability, and platform constraints.

Limitations: TLS protects the channel, not compromised endpoints or data after termination.

Tradeoffs: Validate peer identity and configure current protocol versions and cipher suites.

Storage encryption

Storage encryption protects data on media, volumes, objects, databases, or backups against specified access threats.

Example: Encrypt the relevant media and backups with separated key authority, while retaining controls against a running compromised application.

Counterexample: Delete certificate verification or expose distinct padding, signature, and tag errors to simplify troubleshooting of the cryptographic workflow. | Expose detailed cryptographic failures from data on volumes, objects, and backups so callers can distinguish padding, signature, and key-service errors. | Share nonces or derived keys across purposes because neither value is intended to be secret.

Limitations: Full-disk encryption may not protect data from a running compromised application.

Tradeoffs: Define key separation and who can decrypt.

Cryptographic agility

Agility allows algorithms, protocols, keys, and parameters to be replaced without redesigning the entire application.

Example: Separate cryptographic policy and dependencies from business logic so algorithms, protocols, keys, and parameters can be replaced safely.

Counterexample: Continue using nonces or derived keys across purposes because neither value is intended to be secret. | Turn off certificate verification or expose distinct padding, signature, and tag errors to simplify troubleshooting of the cryptographic workflow. | Disable certificate identity verification for algorithms embedded in business logic after the trust chain validates.

Limitations: Agility does not mean accepting arbitrary algorithms at runtime.

Tradeoffs: Separate cryptographic policy from business logic and inventory dependencies.

Encryption implementation

Encryption must be combined with integrity, nonce or IV management, correct modes, key protection, and authenticated context.

Example: Use authenticated encryption with protected keys and correct nonce or IV handling, binding relevant context as associated data when appropriate.

Counterexample: Reuse keys, nonces, or derived material across purposes in an encrypted message format because the values are not intended to be secret. | Deploy a custom algorithm or protocol because the team can improve workflow-specific performance. | Mandate the longest available key and ignore approved profiles, modes, nonces, integrity, interoperability, and platform constraints.

Limitations: Encryption without authentication can permit undetected modification.

Tradeoffs: Prefer authenticated encryption with associated data where appropriate.

Algorithm selection

Select algorithms based on current standards, threat model, platform, interoperability, performance, and required assurance.

Example: Use the organization-approved cryptographic profile for the platform and threat model.

Counterexample: Document the rule in a document but omit training, automated checks, review criteria, and build enforcement. | Allow each team to reinterpret the requirement independently so the code remains flexible across services handling the implementation. | Regard a successful code scan as proof that every legal and organizational obligation affecting the implementation has been implemented.

Limitations: The longest key is not automatically the best design.

Tradeoffs: Use organization-approved cryptographic profiles.

Nonce and IV management

Many modes require unique or unpredictable nonces or initialization vectors. Reuse can destroy confidentiality or integrity.

Example: Use library-managed nonces that satisfy the mode’s uniqueness or unpredictability rule and prevent reuse under the same key.

Counterexample: Use encryption without authenticated integrity, replay handling, endpoint authorization, or protected key lifecycle. | Recycle nonces or derived keys across purposes on the mistaken premise that reuse is safe when secrecy is not required. | Reuse keys, nonces, or derived material across purposes in authenticated-encryption messages under one key because the values are not intended to be secret.

Limitations: A nonce does not always need secrecy, but often must never repeat under a key.

Tradeoffs: Use library-generated values and track uniqueness requirements.

Random number generation

Security tokens, keys, nonces, and salts require cryptographically secure randomness and correct seeding.

Example: Generate tokens, keys, nonces, and salts with an operating-system or approved cryptographic random source.

Counterexample: Expose detailed cryptographic failures from password-reset tokens so callers can distinguish padding, signature, and key-service errors. | Adopt the longest available key and ignore approved profiles, modes, nonces, integrity, interoperability, and platform constraints. | Reuse keys, nonces, or derived material across purposes in password-reset tokens because the values are not intended to be secret.

Limitations: General-purpose pseudorandom functions are not suitable for secrets.

Tradeoffs: Use operating-system or approved cryptographic generators.

Password hashing

Store passwords using a dedicated, salted, adaptive password-hashing function with organization-approved work factors.

Example: Store passwords with a salted adaptive password-hashing function and an approved work factor that can be upgraded over time.

Counterexample: Distribute nonces or derived keys across purposes because the implementation ignores uniqueness and purpose separation. | Suppress certificate verification or expose distinct padding, signature, and tag errors to simplify troubleshooting of the cryptographic workflow. | Employ encryption while omitting authenticated integrity, replay handling, endpoint authorization, or protected key lifecycle.

Limitations: Fast cryptographic hashes are inappropriate for password storage.

Tradeoffs: Support work-factor upgrades and protect reset workflows.

Key derivation

Use approved key-derivation functions with appropriate salt, context, and work factor to derive keys from passwords or master secrets.

Example: Use an approved derivation function with salt and purpose-specific context, producing separate keys for encryption and authentication.

Counterexample: Reuse keys, nonces, or derived material across purposes in keys derived from a master secret because the values are not intended to be secret. | Apply a custom algorithm or protocol because the team can improve workflow-specific performance. | Select a familiar algorithm for keys derived from a master secret and omit integrity, key lifecycle, nonce, identity, or error-handling requirements.

Limitations: Using the same derived key for encryption and authentication increases coupling and risk.

Tradeoffs: Separate keys by purpose and context.

Certificate validation

Validate trust chain, hostname or service identity, validity, revocation strategy, key usage, and algorithm constraints.

Example: Use the platform verifier for trust chain, service identity, validity, key usage, algorithms, and revocation checks.

Counterexample: Handle browser validation because the browser is trusted to preserve the submitted values. | Preserve a long list of known bad strings as the sole criterion for accepting the value. | Continually decode input until it looks normal, before authorizing the final decoded form without a single canonical representation.

Limitations: Disabling certificate verification for testing must not reach production.

Tradeoffs: Use platform validation unless a reviewed specialized profile is required.

Cryptographic error handling

Treat authentication failure, padding failure, invalid signatures, and key-service errors consistently without leaking oracle information.

Example: Handle tag, signature, padding, and key-service failures through uniform library primitives that do not expose oracle distinctions.

Counterexample: Run cleanup only after success, leaving locks, sessions, transactions, temporary data, or keys allocated when an error occurs on the failure path. | Terminate the entire service for each minor error even when policy permits a bounded and safe local failure. | Treat encryption of signature, tag, and padding failures as a substitute for authorization, endpoint security, and data minimization.

Limitations: Detailed cryptographic error differences can become side channels.

Tradeoffs: Use constant-behavior library primitives where possible.

Access control

Enforce access at the authoritative server-side operation using authenticated identity, policy, object ownership, function permission, and contextual constraints.

Example: Authorize the authenticated subject for the exact server-side operation and object, including ownership, function permission, and context, with default denial.

Counterexample: Give the privileged service identity authority for every caller’s requested action without scoped delegation or audience checks. | Rely on an internal network, hidden route, missing button, route name, or client-provided tenant value instead of mediating the protected operation. | Use broad roles or uncontrolled attributes that are convenient to assign but cannot demonstrate least privilege or separation of duty.

Limitations: Authentication is not authorization.

Tradeoffs: Deny by default and mediate every protected operation.

Trust zones

Trust zones group components with similar trust assumptions and control requirements. Crossing a zone requires explicit mediation.

Example: Mediate every zone crossing explicitly and base trust on identity, policy, and context rather than internal network location.

Counterexample: Build broad roles or uncontrolled attributes that are convenient to assign but cannot demonstrate least privilege or separation of duty. | Permit the privileged service identity authority for every caller’s requested action without scoped delegation or audience checks. | Cache the allow decision indefinitely and keep using it after role, policy, ownership, context, or revocation changes.

Limitations: An internal network is not automatically trusted.

Tradeoffs: Do not infer trust solely from network location.

Function permissions

Function-level authorization controls which operations a subject may invoke, independent of whether the interface exposes them.

Example: Check permission for the exact business function at the service boundary even when the UI hides or omits the operation.

Counterexample: Employ broad roles or uncontrolled attributes that are convenient to assign but cannot demonstrate least privilege or separation of duty. | Authorize the request because the caller is authenticated and the object identifier is difficult to guess. | Assume an internal network, hidden route, missing button, route name, or client-provided tenant value instead of mediating the protected operation.

Limitations: Hiding an admin button is not function-level authorization.

Tradeoffs: Check permission at the business operation.

Role-based access control

RBAC assigns permissions through roles aligned to job functions.

Example: Define narrow job-aligned roles, govern assignment and inheritance, and detect separation-of-duty conflicts instead of granting broad convenience roles.

Counterexample: Trust an internal network, hidden route, missing button, route name, or client-provided tenant value instead of mediating the protected operation. | Retain the allow decision indefinitely and keep using it after role, policy, ownership, context, or revocation changes. | Assign the privileged service identity authority for every caller’s requested action without scoped delegation or audience checks.

Limitations: RBAC does not automatically provide least privilege if roles are broad.

Tradeoffs: Control role design, assignment, inheritance, and separation-of-duty conflicts.

Discretionary access control

DAC allows an owner or authorized subject to delegate access within policy constraints.

Example: Allow owner-directed sharing only within policy limits, with auditable delegation and controls on onward permission propagation.

Counterexample: Keep the allow decision indefinitely and keep using it after role, policy, ownership, context, or revocation changes. | Create broad roles or uncontrolled attributes that are convenient to assign but cannot demonstrate least privilege or separation of duty. | Accept an internal network, hidden route, missing button, route name, or client-provided tenant value instead of mediating the protected operation.

Limitations: DAC is not inherently unsuitable, but can increase permission propagation risk.

Tradeoffs: Use where owner-driven sharing is a business requirement.

Mandatory access control

MAC enforces centrally defined labels and clearances that ordinary users cannot override.

Example: Enforce centrally controlled labels and clearances that ordinary users cannot override, preserving the required information-flow policy.

Counterexample: Grant the privileged service identity authority for every caller’s requested action while omitting scoped delegation or audience checks. | Approve an internal network, hidden route, missing button, route name, or client-provided tenant value instead of mediating the protected operation. | Authorize labeled records and user clearances from authentication, route visibility, or a client-supplied identifier without checking the exact action and resource.

Limitations: MAC is not simply “administrator-controlled RBAC.”.

Tradeoffs: Use when classification and information-flow policy require it.

Object-level authorization

Every request for a specific record or resource must verify the subject’s authority over that object.

Example: Bind the authenticated subject, tenant, and ownership criteria into the data query for every requested object.

Counterexample: Rely on broad roles or uncontrolled attributes that are convenient to assign but cannot demonstrate least privilege or separation of duty. | Grant the privileged service identity authority for every caller’s requested action without scoped delegation or audience checks. | Trust an internal network or service identity to authorize an invoice named in an API request for every caller and tenant.

Limitations: Guess-resistant identifiers do not replace authorization.

Tradeoffs: Bind tenant and ownership context to the query itself.

Broken object-level authorization (BOLA / IDOR)

BOLA occurs when an API accepts an object identifier but fails to verify that the authenticated caller is authorized for that specific object. IDOR is a common manifestation of this weakness.

Example: Verify server-side authority for the specific object on every direct and indirect reference, binding tenant or ownership context into retrieval.

Counterexample: Allow a privileged deputy to perform an invoice named in an API request without scoped delegation, audience binding, or caller-intent validation. | Cache the authorization decision for an invoice named in an API request indefinitely despite policy, role, ownership, or revocation changes. | Depend on an internal network, hidden route, missing button, route name, or client-provided tenant value rather than authorizing the exact action and resource at the service boundary.

Limitations: Unpredictable identifiers, hidden fields, client-side checks, or authentication alone do not prevent BOLA.

Tradeoffs: Enforce authorization for every object access on the server, bind tenant or ownership context to the data query, and test both direct and indirect object references.

Broken function-level authorization (BFLA)

BFLA occurs when a caller can invoke an administrative, privileged, or role-restricted API function without an effective server-side authorization decision for that operation.

Example: Authorize the exact administrative or privileged action at the service boundary regardless of route visibility, documentation, or authentication status.

Counterexample: Presume an internal network, hidden route, missing button, route name, or client-provided tenant value without an authoritative decisioned function and object. | Reuse the allow decision indefinitely and keep using it after role, policy, ownership, context, or revocation changes. | Allow the privileged service identity authority for every caller’s requested action while omitting scoped delegation or audience checks.

Limitations: Hiding an endpoint, removing a button, relying on route names, or checking only that the caller is authenticated does not provide function-level authorization.

Tradeoffs: Authorize the exact function, action, and privilege level at the service boundary regardless of whether the endpoint is documented or exposed in the user interface.

Attribute-based access control

ABAC evaluates subject, resource, action, and environment attributes to make contextual decisions.

Example: Govern subject, resource, action, and environment attributes and keep the policy reviewable enough to explain contextual decisions.

Counterexample: Continue using the allow decision indefinitely and keep using it after role, policy, ownership, context, or revocation changes. | Cache the authorization decision for a policy using subject, resource, action, and environment attributes indefinitely despite policy, role, ownership, or revocation changes. | Hide the privileged interface for a policy using subject, resource, action, and environment attributes and omit server-side function- and object-level authorization.

Limitations: ABAC can become difficult to audit if policy and attributes are uncontrolled.

Tradeoffs: Govern attribute integrity and policy complexity.

Authorization caching

Cached decisions require bounded lifetime, context binding, revocation handling, and invalidation after policy or role change.

Example: Bind cached decisions to context, use a bounded lifetime, and invalidate them after role, policy, ownership, or revocation changes.

Counterexample: Enable the privileged service identity authority for every caller’s requested action while omitting scoped delegation or audience checks. | Trust an internal network or service identity to authorize a cached decision after a role change for every caller and tenant. | Define broad roles or uncontrolled attributes that are convenient to assign but without proving least privilege or detecting separation-of-duty conflicts.

Limitations: Performance is not justification for indefinite authorization caching.

Tradeoffs: Cache only when stale authorization risk is acceptable.

Confused deputy prevention

A privileged component must verify that a caller is authorized for the exact delegated action and resource.

Example: Verify that the caller is authorized for the exact delegated action and resource, using scoped capability and audience information.

Counterexample: Use broad roles or uncontrolled attributes for a privileged export service acting for callers without separation-of-duty or integrity governance. | Hide the privileged interface for a privileged export service acting for callers and omit server-side function- and object-level authorization. | Allow a privileged deputy to perform a privileged export service acting for callers without scoped delegation, audience binding, or caller-intent validation.

Limitations: A trusted service identity does not authorize every requester’s intent.

Tradeoffs: Use capability scoping, audience binding, and explicit delegation.

Processor microarchitecture security extensions

Implementation may use platform capabilities such as memory protection keys, control-flow enforcement, pointer authentication, enclaves, execute-disable, or branch protections.

Example: Enable supported hardware and compiler mitigations as defense in depth while retaining safe application logic.

Counterexample: Adopt execute protection or control-flow enforcement alone and ignore code-reuse, side-channel, update, and business-logic risks. | Treat the hardware or compiler feature as proof that application logic, authorization, input handling, and memory use are secure. | Deploy the mitigation in only one module and assume unprotected libraries and alternate control paths receive the same protection.

Limitations: Hardware support does not compensate for insecure application logic.

Tradeoffs: Enable and correctly integrate supported mitigations according to the platform threat model.

Memory execute protections

Data execution prevention and non-executable memory reduce exploitation by preventing execution from designated data regions.

Example: Compile and deploy compatible non-executable memory protections, supplementing them with memory safety and defenses against code reuse.

Counterexample: Apply the mitigation in only one module and assume unprotected libraries and alternate control paths receive the same protection. | Move a large complex parser and all sensitive logic into the enclave because confidential execution makes its input trustworthy. | Assume the platform-specific extension is a portable guarantee and omit fallback behavior on unsupported systems.

Limitations: They do not prevent code-reuse attacks by themselves.

Tradeoffs: Compile and deploy with compatible protections.

Control-flow integrity extensions

Hardware or compiler-assisted control-flow protections constrain indirect branches and returns.

Example: Enable compatible compiler and platform control-flow protections across all relevant modules without treating them as business authorization.

Counterexample: Shift a large complex parser and all sensitive logic into the enclave because confidential execution makes its input trustworthy. | Use execute protection or control-flow enforcement alone and ignore code-reuse, side-channel, update, and business-logic risks. | Turn on the mitigation in only one module and assume unprotected libraries and alternate control paths receive the same protection.

Limitations: Control-flow protection does not validate business authorization.

Tradeoffs: Use toolchain and platform features together.

Pointer authentication and memory tagging

Pointer authentication and memory tagging can detect classes of pointer corruption and memory misuse on supported platforms.

Example: Use supported pointer authentication or memory tagging as defense in depth around portable memory-safe design and validation.

Counterexample: Presume the platform-specific extension is a portable guarantee and omit fallback behavior on unsupported systems. | Enable the mitigation in only one module and assume unprotected libraries and alternate control paths receive the same protection. | Apply execute protection or control-flow enforcement alone and ignore code-reuse, side-channel, update, and business-logic risks.

Limitations: Platform-specific extensions are not portable guarantees.

Tradeoffs: Treat them as defense in depth around memory-safe design.

Trusted execution environments

Enclaves and confidential-computing features can protect selected code and data from parts of the host environment.

Example: Minimize enclave code and design attestation, sealing, updates, input validation, and side-channel controls for the protected function.

Counterexample: Choose execute protection or control-flow enforcement alone and ignore code-reuse, side-channel, update, and business-logic risks. | Treat the platform-specific extension is a portable guarantee and omit fallback behavior on unsupported systems. | Implement only the visible path for an enclave processing sensitive keys while leaving alternate interfaces, failure paths, and authoritative checks unimplemented.

Limitations: A TEE does not make untrusted input or flawed code safe.

Tradeoffs: Minimize enclave code and design attestation, sealing, update, and side-channel controls.

Analyze code for security risks

Code analysis identifies weaknesses, malicious behavior, unsafe assumptions, and deviations from approved implementation standards before release.

Example: Combine automated and manual techniques because each has different strengths and blind spots.

Counterexample: Retain only a green dashboard screenshot without tool version, rules, scope, configuration, findings, suppressions, or decisions. | Close duplicate findings individually without confirming that the underlying shared weakness and affected versions are remediated. | Suppress the finding permanently with no owner, scope, rationale, expiry, review date, or risk decision.

Limitations: A clean scan is not evidence that code is vulnerability free.

Tradeoffs: Combine automated and manual techniques because each has different strengths and blind spots.

Secure code reuse

Reuse should favor reviewed, maintained, provenance-known components and safe abstractions rather than copying insecure snippets or reinventing security-sensitive code.

Example: Reuse reduces defects only when the reused component and integration are trustworthy.

Counterexample: Reimplement the security-sensitive function from scratch so the team does not depend on another maintained component. | Paste the code directly instead of using a controlled dependency or reviewed template that retains provenance and update paths. | Adopt the common security library without narrow interfaces, version ownership, support, integration review, or systemic-risk planning.

Limitations: Reuse is not automatically secure.

Tradeoffs: Reuse reduces defects only when the reused component and integration are trustworthy.

Reuse of common security controls

Central libraries for authentication, authorization, validation, cryptography, and logging can improve consistency and reduce duplicated defects.

Example: Keep interfaces narrow, versioned, and supported, preserving the approved implementation outcome for reused security-sensitive code.

Counterexample: Assume the reused component because it is popular or reviewed elsewhere, while preserving excessive privilege and unsafe calling assumptions. | Choose the common security library while omitting narrow interfaces, version ownership, support, integration review, or systemic-risk planning. | Paste the code immediately instead of using a controlled dependency or reviewed template that retains provenance and update paths.

Limitations: A vulnerable common control can create systemic exposure.

Tradeoffs: Keep interfaces narrow, versioned, and supported.

Copy-paste security risk

Copied code can preserve hidden assumptions, outdated dependencies, licenses, secrets, and vulnerabilities while losing provenance.

Example: Prefer dependency-based reuse or documented templates over anonymous snippets.

Counterexample: Close the analysis of an anonymous code snippet copied into payment logic from a green dashboard without preserving scope, rules, tool version, suppressions, or review decisions. | Accept the reused component because it is popular or reviewed elsewhere, while preserving excessive privilege and unsafe calling assumptions. | Use one automated technique for an anonymous code snippet copied into payment logic and omit complementary manual or behavioral evidence.

Limitations: Changing variable names does not remove inherited risk.

Tradeoffs: Prefer dependency-based reuse or documented templates over anonymous snippets.

Vulnerability databases and lists

Weakness and vulnerability catalogs provide common terminology, examples, mappings, and prioritization inputs for code analysis and education.

Example: Use OWASP for broad risk categories, CWE for weakness classes, and CVE for disclosed vulnerability instances.

Counterexample: Assume a category absent from the selected awareness list is outside the implementation security review scope. | Use a CVE catalog to answer a weakness-class question and treat each CWE entry as a disclosed product vulnerability. | Regard the OWASP awareness list or Top 25 as a complete standard whose ranking overrides application-specific risk.

Limitations: Do not treat every catalog as a list of specific product vulnerabilities.

Tradeoffs: Use the correct catalog for the question: weakness class, known vulnerability, or broad risk category.

OWASP Top 10

The OWASP Top 10 is an awareness document grouping major web application security risk categories.

Example: Use the OWASP Top 10 to guide awareness and review coverage without treating it as a complete security standard.

Counterexample: Treat the OWASP awareness list or Top 25 as a complete standard whose ranking overrides application-specific risk. | Adopt any catalog interchangeably because all lists describe the same level of vulnerability detail and scope. | Close the analysis after mapping a label, without reviewing reachability, affected versions, exploitability, or business impact.

Limitations: Passing the Top 10 does not prove comprehensive security.

Tradeoffs: Use it to guide awareness and review coverage, not as a complete standard.

Common Weakness Enumeration

CWE catalogs software and hardware weakness types such as injection, memory safety, authorization, and resource-management errors.

Example: Classify the root weakness with CWE rather than treating the entry as a specific disclosed product vulnerability.

Counterexample: Resolve duplicate findings individually without confirming that the underlying shared weakness and affected versions are remediated. | Assume a clean automated result eliminates the need for complementary manual review and malicious-code inspection. | Keep only a green dashboard screenshot while omitting tool version, rules, scope, configuration, findings, suppressions, or decisions.

Limitations: CWE entries are not the same as CVE records.

Tradeoffs: Use CWE to classify root weakness patterns.

SANS/CWE Top 25

The Top 25 highlights widespread and severe software weakness classes for education and prioritization.

Example: Use the Top 25 as a prioritization aid and adjust the order for the application’s actual reachability, impact, and exposure.

Counterexample: Resolve the analysis after mapping a label, without reviewing reachability, affected versions, exploitability, or business impact. | Consider the OWASP awareness list or Top 25 as a complete standard whose ranking overrides application-specific risk. | Presume a category absent from the selected awareness list is outside the implementation security review scope.

Limitations: Its ranking should not override application-specific risk.

Tradeoffs: Use it as a prioritization aid, not a complete taxonomy.

CVE versus CWE

CVE identifies publicly disclosed vulnerability instances, CWE describes weakness classes that can cause vulnerabilities.

Example: Record the disclosed instance as a CVE and map its underlying weakness pattern to the relevant CWE where appropriate.

Counterexample: Treat a category absent from the selected awareness list is outside the implementation security review scope. | Dismiss the analysis after mapping a label, without reviewing reachability, affected versions, exploitability, or business impact. | Choose any catalog interchangeably because all lists describe the same level of vulnerability detail and scope.

Limitations: Do not answer a weakness-class question with a CVE catalog.

Tradeoffs: A CVE may map to one or more CWEs.

Static application security testing

SAST analyzes source, bytecode, or binaries without executing the full application to identify data-flow, control-flow, API, and pattern-based weaknesses.

Example: Run tuned SAST early and combine its results with manual review and runtime evidence.

Counterexample: Focus only on changed code and allow reachable high-risk baseline findings to remain exempt indefinitely. | Regard the green scan as proof that runtime configuration, environment interaction, business logic, and all vulnerabilities are secure. | Suppress noisy rules broadly without validating the findings, measuring escaped weaknesses, or preserving high-risk coverage.

Limitations: SAST cannot observe every runtime configuration or environment interaction.

Tradeoffs: Run early and tune rules to the language and risk profile.

Automated code coverage in implementation analysis

Automated analysis coverage indicates which files, languages, rules, or paths the tool examined, it does not necessarily mean test execution coverage.

Example: Define which files, languages, rules, and paths the analysis covered instead of calling it test coverage.

Counterexample: Turn off noisy rules broadly without validating the findings, measuring escaped weaknesses, or preserving high-risk coverage. | Count analyzed files as unit-test coverage and infer that every executable branch has been exercised. | Treat the linter as a complete interprocedural analyzer for authorization, data flow, and framework behavior.

Limitations: Do not confuse SAST coverage with unit-test line or branch coverage.

Tradeoffs: Define what “coverage” means in the tool and report.

Linting

Linters identify style defects, suspicious constructs, unsafe APIs, and selected security patterns using language-aware rules.

Example: Use security-focused lint rules for local patterns, and escalate data-flow or business-logic questions to deeper analysis.

Counterexample: Count analyzed files as unit-test coverage and infer that each executable branch has been exercised. | Restrict analysis only on changed code and allow reachable high-risk baseline findings to remain exempt indefinitely. | Disable noisy rules broadly without validating the findings, measuring escaped weaknesses, or preserving high-risk coverage.

Limitations: A linter is not a full interprocedural security analyzer.

Tradeoffs: Use security-focused rules and enforce justified exceptions.

SAST data-flow analysis

Data-flow or taint analysis tracks data from sources through transformations to sensitive sinks.

Example: Review source-to-sink paths, sanitizer assumptions, and framework models, recognizing both infeasible reports and missing model coverage.

Counterexample: Regard the linter as a complete interprocedural analyzer for authorization, data flow, and framework behavior. | Suppress noisy rules affecting tainted data moving from a request to a sensitive sink without validating findings or measuring escaped weaknesses. | Concentrate only on changed code and allow reachable high-risk baseline findings to remain exempt indefinitely.

Limitations: A reported path may be infeasible, a missed framework model may create false negatives.

Tradeoffs: Review sanitization assumptions and framework models.

SAST control-flow analysis

Control-flow analysis reasons about possible execution paths, branches, calls, and state transitions.

Example: Use control-flow analysis to inspect branches, calls, state transitions, unreachable controls, and unsafe error paths while accounting for path explosion.

Counterexample: Focus solely on changed code and allow reachable high-risk baseline findings to remain exempt indefinitely. | Depend on the linter as a complete interprocedural analyzer for authorization, data flow, and framework behavior. | Suppress noisy rules affecting branches, calls, and error paths without validating findings or measuring escaped weaknesses.

Limitations: Path explosion limits completeness.

Tradeoffs: Use it to find unreachable controls, unsafe error paths, and bypasses.

SAST false positives and false negatives

False positives consume review effort, false negatives create false assurance. Tuning must preserve important coverage.

Example: Tune noisy findings with evidence while measuring escaped weaknesses and preserving high-risk rule coverage.

Counterexample: Concentrate solely on changed code and allow reachable high-risk baseline findings to remain exempt indefinitely. | Treat the green scan as proof that runtime configuration, environment interaction, business logic, and all vulnerabilities are secure. | Remove noisy rules broadly without validating the findings, measuring escaped weaknesses, or preserving high-risk coverage.

Limitations: Suppressing noisy rules without analysis can hide real vulnerabilities.

Tradeoffs: Measure precision and escaped findings, not only finding counts.

SAST baseline and differential analysis

Baselining distinguishes existing debt from new findings, differential analysis focuses review on changed code.

Example: Focus differential review on changed code without allowing the baseline to permanently exempt reachable high-risk legacy findings.

Counterexample: Dismiss noisy rules broadly without true findings, escaped weaknesses, or the high-risk coverage lost by the suppression. | Describe analyzed files as unit-test coverage and infer that every executable branch has been exercised. | Rely on the linter as a complete interprocedural analyzer for authorization, data flow, and framework behavior.

Limitations: “No new findings” does not mean the application is secure.

Tradeoffs: Do not let the baseline permanently exempt high-risk legacy vulnerabilities.

SAST custom rules

Custom rules can identify organization-specific dangerous APIs, frameworks, annotations, and insecure patterns.

Example: Validate each custom rule with positive and negative examples and track coverage so organization-specific models do not create broad blind spots.

Counterexample: Describe analyzed files as unit-test coverage and infer that each executable branch has been exercised. | Treat a clean automated result for organization-specific dangerous APIs and annotations as proof that runtime configuration, business logic, and malicious behavior are safe. | Disable noisy rules broadly without the rule’s precision, missed weaknesses, and remaining high-risk detection.

Limitations: Poor custom rules can create broad blind spots.

Tradeoffs: Test rules with positive and negative examples.

Manual code review

Human review evaluates business logic, authorization intent, error paths, misuse, maintainability, and context that tools may not understand.

Example: Use qualified human review for business logic, authorization intent, negative paths, maintainability, and context beyond automated tool models.

Counterexample: Review the cryptographic library name but omit modes, nonces, certificates, key derivation, exposure, and failure behavior. | Adopt one reviewer with the same assumptions as the author for critical code and treat approval count as sufficient independence. | Analyze a sequential path about state changes and retries, assuming concurrency and duplicate processing cannot alter the security outcome.

Limitations: Manual review is not merely style review.

Tradeoffs: Use risk-based checklists, traceability, and reviewer independence where warranted.

Peer review

Peer review has another qualified developer inspect changes before integration, improving defect detection and knowledge sharing.

Example: Require a qualified peer before integration and add specialist security review when the change’s impact or domain demands it.

Counterexample: Review only sequential behavior about state changes and retries, assuming concurrency and duplicate processing cannot alter the security outcome. | Check the cryptographic library name but omit modes, nonces, certificates, key derivation, exposure, and failure behavior. | Note that an authorization helper exists without tracing every protected operation, worker, object, and negative path that should call it.

Limitations: Approval by a peer does not replace specialized security review when risk is high.

Tradeoffs: Require appropriate expertise for security-sensitive changes.

Four-eyes principle for critical code

Critical cryptographic, authorization, payment, update, or safety logic may require independent review by more than one qualified person.

Example: Require independent qualified review for critical payment, update, cryptographic, authorization, or safety logic in proportion to impact.

Counterexample: Assess a sequential path about state changes and retries, assuming concurrency and duplicate processing cannot alter the security outcome. | Limit the review to style, compilation, and the expected happy path, omitting business abuse, privilege transitions, and alternate interfaces. | Use one reviewer with the same assumptions as the author for critical code and treat approval count as sufficient independence.

Limitations: More reviewers do not help if all share the same incorrect assumption.

Tradeoffs: Apply proportional assurance based on impact.

Review of authorization logic

Trace each protected operation from entry point to authoritative policy check, including alternate APIs, background jobs, and object access.

Example: Trace every entry point and alternate path to the authoritative authorization check, including workers and privilege transitions.

Counterexample: Rely on one reviewer with the same assumptions as the author for critical code and treat approval count as sufficient independence. | Confirm that an authorization helper exists without tracing every protected operation, worker, object, and negative path that should call it. | Inspect the cryptographic library name but omit modes, nonces, certificates, key derivation, exposure, and failure behavior.

Limitations: Presence of an authorization helper does not prove it is called everywhere.

Tradeoffs: Review negative paths and privilege transitions.

Review of business logic

Business-logic review examines sequencing, limits, replay, duplication, approvals, state machines, and economic abuse.

Example: Review sequence, limits, duplication, replay, approvals, state transitions, and economic abuse from the attacker’s goal rather than only malformed input.

Counterexample: Inspect sequential behavior for sequence, replay, limits, and approvals but ignore retries, duplicate processing, and concurrent state transitions. | Inspect only sequential behavior about state changes and retries, assuming concurrency and duplicate processing cannot alter the security outcome. | Apply one reviewer with the same assumptions as the author for critical code and treat approval count as sufficient independence.

Limitations: Generic injection scanners rarely understand business abuse.

Tradeoffs: Model attacker goals, not only malformed input.

Review of cryptographic use

Verify algorithm profile, modes, nonce handling, randomness, key derivation, certificate validation, failure behavior, and key exposure.

Example: Review the full cryptographic workflow, including profile, modes, nonces, randomness, derivation, certificates, failures, keys, and exposure.

Counterexample: Confirm a security helper exists for the complete key and encryption workflow without tracing every entry point and alternate path that should call it. | Approve the complete key and encryption workflow because automated analysis is green and skip human review of context and intent. | Assume sequential execution about state changes and retries, assuming concurrency and duplicate processing cannot alter the security outcome.

Limitations: A recognized library call can still be misconfigured.

Tradeoffs: Review the entire cryptographic workflow.

Review of concurrency and state transitions

Inspect check-use gaps, transaction boundaries, idempotency, duplicate processing, and distributed consistency.

Example: Inspect invariants across retries, transaction boundaries, duplicate processing, distributed consistency, and check-use gaps instead of reasoning only about a sequential happy path.

Counterexample: Review a sequential path about state changes and retries, while ignoring retries, interleavings, and duplicate effects on the security invariant. | Examine the cryptographic library name but omit modes, nonces, certificates, key derivation, exposure, and failure behavior. | Review only the library name used by retries, transactions, and state transitions and omit modes, nonces, certificates, keys, and failure behavior.

Limitations: Happy-path sequential reasoning misses concurrency attacks.

Tradeoffs: Review invariants under retries and concurrent requests.

Inspect for malicious code

Inspection should identify intentionally harmful or unauthorized functionality such as backdoors, logic bombs, credential theft, covert channels, or destructive behavior.

Example: Use provenance, review, binary analysis, entropy, and behavioral evidence to investigate suspected malicious code.

Counterexample: Clear the current secret or suspicious line and leave repository history, generated artifacts, binaries, and live credentials unchanged. | Classify the content as malicious solely because it is high entropy, obfuscated, unusual, scheduled, or communicates with a public cloud. | Regard a valid signature, normal source review, or familiar repository as proof that the shipped binary has no hidden behavior.

Limitations: Unusual code is not automatically malicious, context and evidence matter.

Tradeoffs: Use provenance, review, binary analysis, entropy checks, and behavioral evidence.

Backdoors

A backdoor provides hidden or undocumented access that bypasses normal controls. It may be intentional, malicious, or introduced as an unsafe maintenance mechanism.

Example: Search for hard-coded credentials, bypass flags, hidden endpoints, and alternate authentication paths.

Counterexample: Treat a valid signature, normal source review, or familiar repository as proof that the shipped binary has no hidden behavior. | Ignore undocumented endpoints, bypass flags, credentials, triggers, and dynamic loading because the component passed composition analysis. | Enable a signed plugin broad authority because integrity of the package is assumed to prove safe intent and implementation.

Limitations: A documented emergency-access mechanism is not automatically a backdoor if governed and audited.

Tradeoffs: Search for hard-coded credentials, bypass flags, hidden endpoints, and alternate authentication paths.

Logic bombs

A logic bomb triggers harmful behavior when a condition such as time, identity, event, or state is met.

Example: Determine whether the dormant trigger and harmful action are unauthorized or malicious rather than labeling every scheduled condition as a logic bomb.

Counterexample: Disregard undocumented endpoints, bypass flags, credentials, triggers, and dynamic loading because the component passed composition analysis. | Erase the current secret or suspicious line and leave repository history, generated artifacts, binaries, and live credentials unchanged. | Consider a valid signature, normal source review, or familiar repository as proof that the shipped binary has no hidden behavior.

Limitations: Scheduled legitimate maintenance is not a logic bomb without malicious or unauthorized purpose.

Tradeoffs: Review dormant conditions, destructive actions, and unusual triggers.

High-entropy content

High-entropy regions can indicate compressed, encrypted, packed, or obfuscated content and may warrant investigation.

Example: Use entropy only to prioritize inspection and correlate it with provenance, packing, encryption, compression, and observed behavior.

Counterexample: Activate a signed plugin broad authority because integrity of the package is assumed to prove safe intent and implementation. | Treat a documented and governed emergency path in packed or encrypted regions in a binary as a backdoor solely because it bypasses the normal flow. | Delete the current secret or suspicious line and leave repository history, generated artifacts, binaries, and live credentials unchanged.

Limitations: High entropy alone does not prove malware.

Tradeoffs: Use entropy as a triage signal alongside provenance and behavior.

Hard-coded credentials detection

Search source, configuration, tests, histories, binaries, and generated artifacts for passwords, tokens, keys, and certificates.

Example: Search source, history, tests, binaries, configuration, and artifacts, then revoke and rotate every exposed live credential.

Counterexample: Close the current secret or suspicious line and leave repository history, generated artifacts, binaries, and live credentials unchanged. | Allow a signed plugin broad authority because integrity of the package is assumed to prove safe intent and implementation. | Use one automated technique for live secrets in source, history, and artifacts and omit complementary manual or behavioral evidence.

Limitations: Deleting the current line does not remove repository history.

Tradeoffs: Any exposed live secret must be revoked and rotated.

Suspicious outbound communications

Review unexpected network destinations, beaconing, telemetry, data exfiltration, update channels, and dynamic endpoint construction.

Example: Validate the destination, business purpose, data, frequency, and trust of the communication before concluding that the outbound behavior is malicious.

Counterexample: Remove the current secret or suspicious line and leave repository history, generated artifacts, binaries, and live credentials unchanged. | Label the content as malicious solely because it is high entropy, obfuscated, unusual, scheduled, or communicates with a public cloud. | Treat a valid signature, normal source review, or familiar repository as proof that the shipped binary has no hidden behavior.

Limitations: A call to a public cloud service is not inherently malicious.

Tradeoffs: Validate business purpose and destination trust.

Dynamic code loading

Reflection, plugin loading, eval, runtime compilation, and downloaded code expand the execution boundary and may bypass review.

Example: Restrict dynamic code sources, signatures, permissions, and allowed interfaces.

Counterexample: Assume source review proves the distributed binary for plugins, reflection, and downloaded code was built from the same code and inputs. | Omit undocumented endpoints, bypass flags, credentials, triggers, and dynamic loading because the component passed composition analysis. | Leave a signed plugin broad authority because integrity of the package is assumed to prove safe intent and implementation.

Limitations: A signed plugin can still be vulnerable or overprivileged.

Tradeoffs: Restrict sources, signatures, permissions, and allowed interfaces.

Binary and source correspondence

Reproducible or verifiable builds and provenance help establish that reviewed source corresponds to distributed binaries.

Example: Use reproducible or verifiable build evidence and artifact metadata to establish that the reviewed source corresponds to the distributed binary.

Counterexample: Approve downloaded or dynamically loaded code for the relationship between reviewed source and shipped binaries from a signature alone without privilege and interface review. | Dismiss the current secret or suspicious line while retaining the exposed value in history, artifacts, binaries, and active credentials. | Treat a documented and governed emergency path in the relationship between reviewed source and shipped binaries as a backdoor solely because it bypasses the normal flow.

Limitations: A source review alone does not prove the shipped binary is identical.

Tradeoffs: Compare artifacts and build metadata where assurance requires it.

Code analysis triage

Triage validates findings, estimates exploitability and impact, assigns ownership, and links remediation to requirements and release criteria.

Example: Validate the finding, assess reachability and impact, assign an owner, and tie remediation to release criteria.

Counterexample: Dismiss the finding permanently with no owner, scope, rationale, expiry, review date, or risk decision. | Preserve only a green dashboard screenshot while omitting tool version, rules, scope, configuration, findings, suppressions, or decisions. | Presume a clean automated result eliminates the need for complementary manual review and malicious-code inspection.

Limitations: Closing a duplicate finding does not close the underlying weakness.

Tradeoffs: Prioritize by context rather than tool severity alone.

Code analysis evidence

Retain tool versions, rulesets, scope, configuration, findings, review decisions, suppressions, and remediation evidence.

Example: Retain analyzer version, rules, scope, configuration, findings, suppressions, decisions, and remediation evidence so the result can be reproduced.

Counterexample: Treat a clean automated result eliminates the need for complementary manual review and malicious-code inspection. | Ignore the finding permanently with no owner, scope, rationale, expiry, review date, or risk decision. | Prioritize tool scope, configuration, findings, and review decisions solely from tool severity without reachability, exploitability, impact, or asset context.

Limitations: A screenshot of a green dashboard is weak evidence without scope and configuration.

Tradeoffs: Evidence must be reproducible enough for audit and trend analysis.

Suppression governance

Suppressed findings require documented rationale, scope, owner, expiration or review date, and risk acceptance where appropriate.

Example: Use a precise suppression with rationale, scope, owner, and expiry, obtaining risk acceptance when appropriate instead of disabling the broad rule.

Counterexample: Copy a proposed static-analysis suppression from an anonymous snippet and assume changed variable names remove provenance, license, and vulnerability risk. | Apply the scanner severity as the final business priority and omit reachability, impact, ownership, and release context. | Use one automated technique for a proposed static-analysis suppression and omit complementary manual or behavioral evidence.

Limitations: A suppression is not remediation.

Tradeoffs: Prefer precise suppressions over disabling broad rules.

Implement security controls

Security controls selected by requirements and design must be implemented correctly, consistently, and observably in software and supporting configuration.

Example: Implementation should preserve the control objective and trace to verification evidence.

Counterexample: Bypass the safeguard whenever a policy, key, scanner, or audit dependency is unavailable, without an approved risk-based failure mode. | Record the control in documentation and traceability records without implementing observable behavior on every authoritative path. | Deploy detection without actionable response ownership, escalation, evidence, or a bounded recovery path.

Limitations: A control that exists only in documentation is not implemented.

Tradeoffs: Implementation should preserve the control objective and trace to verification evidence.

Watchdogs

A watchdog detects stalled, unresponsive, or anomalous components and initiates a defined recovery, restart, failover, or alert action.

Example: Use bounded recovery with loop detection, escalation, and state-safety checks so the watchdog cannot amplify an unsafe failure.

Counterexample: Protect the control code but leave its policy, allowlist, signature, baseline, or rule configuration mutable by the application. | Implement detection while omitting actionable response ownership, escalation, evidence, or a bounded recovery path. | Retain the control in documentation and traceability records without implementing observable behavior on every authoritative path.

Limitations: A watchdog can improve availability but may worsen failure if recovery is unsafe.

Tradeoffs: Design bounded recovery and prevent restart loops.

File integrity monitoring

File integrity monitoring detects unauthorized or unexpected changes to selected files, configurations, binaries, and critical metadata.

Example: Protect the integrity baseline and monitor only meaningful files, configurations, binaries, and metadata.

Counterexample: Capture the control in documentation and traceability records without implementing observable behavior on every authoritative path. | Harden the control code but leave its policy, allowlist, signature, baseline, or rule configuration mutable by the application. | Bypass the safeguard whenever a policy, key, scanner, or audit dependency is unavailable, while omitting an approved risk-based failure mode.

Limitations: FIM detects change, it does not identify every cause or prevent every modification.

Tradeoffs: Protect baselines and tune scope to meaningful assets.

Anti-malware controls

Anti-malware controls detect, block, quarantine, or analyze known and suspicious malicious content or behavior.

Example: Combine anti-malware with least privilege, allowlisting, updates, and incident response.

Counterexample: Keep the control in documentation and traceability records without implementing observable behavior on every authoritative path. | Place the safeguard only in the UI, reverse proxy, or documented workflow while alternate APIs and workers can reach the safeguard. | Implement detection without actionable response ownership, escalation, evidence, or a bounded recovery path.

Limitations: Anti-malware is not a substitute for secure implementation.

Tradeoffs: Integrate them with least privilege, allowlisting, updates, and incident response.

Control placement

Place controls where they mediate the authoritative action and cannot be bypassed through alternate interfaces or asynchronous paths.

Example: Place the control on every authoritative path, centralizing only when that reduces inconsistency without unacceptable concentration risk.

Counterexample: Rely on detection without actionable response ownership, escalation, evidence, or a bounded recovery path. | Fail open whenever a policy, key, scanner, or audit dependency is unavailable, without an approved risk-based failure mode. | Secure the control code but leave its policy, allowlist, signature, baseline, or rule configuration mutable by the application.

Limitations: A reverse proxy cannot enforce business-object authorization it cannot understand.

Tradeoffs: Prefer centralized enforcement when it reduces inconsistency without creating unacceptable concentration risk.

Preventive controls

Preventive controls stop or constrain unwanted behavior before impact, such as authorization, validation, sandboxing, and secure defaults.

Example: Use prevention where feasible and layer detection and recovery for failures, bypasses, and conditions that cannot be blocked safely.

Counterexample: Fail open whenever a policy, key, scanner, or audit dependency is unavailable, while omitting an approved risk-based failure mode. | Document authorization and validation on a high-risk path as implemented without observable runtime behavior or failure telemetry. | Add monitoring without actionable response ownership, escalation, evidence, or a bounded recovery path.

Limitations: Prevention alone is insufficient where failures and bypasses remain possible.

Tradeoffs: Use preventive controls for high-risk paths when feasible.

Detective controls

Detective controls identify suspicious or unauthorized activity through logs, monitoring, integrity checks, and anomaly detection.

Example: Define actionable signals, ownership, escalation, and response so detection leads to a risk-reducing decision.

Counterexample: Document monitoring that identifies suspicious activity as implemented without observable runtime behavior or failure telemetry. | Introduce monitoring while omitting a response owner, escalation criteria, evidence preservation, or a safe recovery action. | Document the control in documentation and traceability records without implementing observable behavior on every authoritative path.

Limitations: Detection without response capability does not reduce risk effectively.

Tradeoffs: Define response ownership and actionable signals.

Corrective and recovery controls

Corrective controls restore a secure state through rollback, revocation, quarantine, failover, and recovery.

Example: Bound automatic rollback, revocation, quarantine, or failover, validate the trigger, preserve evidence, and test restoration to a secure state.

Counterexample: Preserve the control in documentation and traceability records while leaving authoritative execution paths without enforceable and observable behavior. | Restrict the control code but leave its policy, allowlist, signature, baseline, or rule configuration mutable by the application. | Implement rollback, revocation, quarantine, and recovery on one visible interface and leave alternate APIs, workers, and maintenance paths able to bypass it.

Limitations: Automatic remediation can cause harm if the trigger is inaccurate or the action is unbounded.

Tradeoffs: Test recovery behavior and preserve evidence.

Compensating controls

A compensating control provides alternative risk reduction when the preferred control is infeasible, while preserving the intended security objective as closely as possible.

Example: Demonstrate comparable risk reduction, limitations, approval, and review for the alternative safeguard rather than selecting it only because it is cheaper.

Counterexample: Add detection for an alternative safeguard while the preferred control is unavailable without response ownership, escalation, evidence preservation, or bounded recovery. | Put the safeguard only in the UI, reverse proxy, or documented workflow while alternate APIs and workers can reach the safeguard. | Document an alternative safeguard while the preferred control is unavailable as implemented without observable runtime behavior or failure telemetry.

Limitations: A cheaper control is not automatically a valid compensating control.

Tradeoffs: Document equivalence, limitations, approval, and review.

Control composition

Controls interact, one control may depend on identity, time, configuration, or another service. Evaluate combined failure modes and gaps.

Example: Evaluate the controls together under shared identity, time, configuration, and dependency failures instead of duplicating the same safeguard.

Counterexample: Deploy detection while omitting ownership, actionable thresholds, investigative evidence, and bounded recovery. | Permit access whenever a policy, key, scanner, or audit dependency is unavailable, without an approved risk-based failure mode. | Implement layered controls sharing identity, time, and configuration dependencies on one visible interface and leave alternate APIs, workers, and maintenance paths able to bypass it.

Limitations: Defense in depth is not simply duplicating identical controls.

Tradeoffs: Test layered controls together, not only individually.

Control bypass resistance

Implementation must prevent bypass through direct API access, alternate protocols, cached decisions, background workers, or privileged maintenance paths.

Example: Enumerate and mediate direct APIs, alternate protocols, cached paths, workers, and privileged maintenance flows to the protected action.

Counterexample: Allow access whenever a policy, key, scanner, or audit dependency is unavailable, while omitting an approved risk-based failure mode. | Preserve the control in documentation and traceability records without implementing observable behavior on each authoritative path. | Depend on detection while omitting a team accountable for response, escalation, evidence, or recovery.

Limitations: UI restrictions do not prove bypass resistance.

Tradeoffs: Enumerate all execution paths to the protected operation.

Control observability

A security control should produce enough telemetry to confirm use, failure, denial, and administrative change without exposing sensitive data.

Example: Emit stable events for use, denial, failure, and administrative change without exposing sensitive data needed by the control.

Counterexample: Add detection for security decisions, denials, failures, and policy changes without response ownership, escalation, evidence preservation, or bounded recovery. | Protect the code for security decisions, denials, failures, and policy changes but leave its policy, baseline, signatures, or allowlist mutable by the application. | Document security decisions, denials, failures, and policy changes as implemented without observable runtime behavior or failure telemetry.

Limitations: A control that cannot be observed is difficult to operate and verify.

Tradeoffs: Instrument security decisions with stable event identifiers.

Control failure behavior

Define behavior when a dependency, policy service, key service, scanner, or audit sink is unavailable.

Example: Choose a policy-defined fail-secure, degraded, queued, or manual path for the dependency outage instead of accepting an implicit fail-open.

Counterexample: Duplicate the same control around an unavailable policy or key service and call it defense in depth without evaluating shared failure modes. | Protect the code for an unavailable policy or key service but leave its policy, baseline, signatures, or allowlist mutable by the application. | Document an unavailable policy or key service as implemented without observable runtime behavior or failure telemetry.

Limitations: Fail-open for availability must not be chosen implicitly.

Tradeoffs: Select fail-secure, degraded, queued, or manually approved behavior according to risk.

Control configuration integrity

Protect control settings, policy files, rule sets, signatures, allowlists, and baselines from unauthorized change.

Example: Protect policies, rules, signatures, allowlists, and baselines with version control, authorization, integrity verification, and change audit.

Counterexample: Document policy files, rule sets, signatures, and baselines complete even though runtime enforcement and failure telemetry are absent. | Position the safeguard only in the UI, reverse proxy, or documented workflow while alternate APIs and workers can reach the safeguard. | Implement policy files, rule sets, signatures, and baselines on one visible interface and leave alternate APIs, workers, and maintenance paths able to bypass it.

Limitations: A secure control with mutable unprotected policy is not trustworthy.

Tradeoffs: Use version control, signatures, access control, and change audit.

Control implementation traceability

Link each implementation to requirement, design decision, code/configuration artifact, owner, and planned verification.

Example: Link the requirement and design decision to the code or configuration artifact, accountable owner, and planned verification evidence.

Counterexample: Introduce detection while omitting defined response ownership, decision thresholds, evidence handling, and recovery limits. | Continue processing whenever a policy, key, scanner, or audit dependency is unavailable, without an approved risk-based failure mode. | Protect the code for requirements, design decisions, code, configuration, and planned verification but leave its policy, baseline, signatures, or allowlist mutable by the application.

Limitations: Traceability alone does not prove effectiveness.

Tradeoffs: Traceability supports change impact and prevents orphan controls.

Address identified security risks

Implementation findings and known risks must be addressed through an approved risk strategy, with ownership, rationale, due dates, and traceability.

Example: Address the root cause through an approved strategy with accountable ownership, contextual priority, due dates, and traceability.

Counterexample: Move financial consequences to a provider and assume the organization no longer retains technical responsibility or residual risk. | Prioritize or close the risk from the raw severity, ticket status, or release date without considering reachability, impact, and evidence. | Use a temporary mitigation without an owner, expiry, review trigger, permanent fix, or validation of comparable risk reduction.

Limitations: A scanner severity is not the same as final business risk.

Tradeoffs: Fix root causes where feasible and prioritize by business context.

Risk strategy

Common strategies include mitigate, avoid, transfer/share, and accept, subject to organizational terminology and authority.

Example: Use an explicit risk strategy approved by the authorized risk owner.

Counterexample: Apply a temporary mitigation without an owner, expiry, review trigger, permanent fix, or validation of comparable risk reduction. | Shift financial consequences to a provider and assume the organization no longer retains technical responsibility or residual risk. | Classify the deferred item security debt or a suppression and treat that label as indefinite acceptance of the identified exposure.

Limitations: Developers and scanners do not have inherent authority to accept business risk.

Tradeoffs: The chosen strategy must be explicit and approved by the correct owner.

Risk mitigation

Mitigation reduces likelihood, impact, exposure, or exploitability through code changes, configuration, architecture, controls, or process improvements.

Example: Change the code, configuration, control, or design that reduces the actual likelihood, impact, exposure, or exploitability of the weakness.

Counterexample: Employ a temporary mitigation while omitting an owner, expiry, review trigger, permanent fix, or validation of comparable risk reduction. | Let the developer, scanner, supplier, or remediation analyst accept the residual business exposure without the accountable owner. | Set the risk priority from the raw severity, ticket status, or release date without considering reachability, impact, and evidence.

Limitations: Changing a warning message is not mitigation of the underlying vulnerability.

Tradeoffs: Verify that the mitigation addresses the root weakness and does not introduce new risk.

Risk avoidance

Avoidance removes the risky feature, dependency, data use, privilege, or exposure entirely.

Example: Remove the risky feature, dependency, data use, privilege, or exposure completely when its benefit does not justify residual risk.

Counterexample: Resolve the risk from the raw severity, ticket status, or release date without considering reachability, impact, and evidence. | Record the deferred item as security debt or a suppression and treat that label as indefinite acceptance of the identified exposure. | Transfer financial consequences to a provider and assume the organization no longer retains technical responsibility or residual risk.

Limitations: Disabling only the UI may not remove the underlying capability.

Tradeoffs: Consider avoidance when benefit does not justify residual risk.

Risk transfer or sharing

Contracts, insurance, managed services, and shared responsibility may allocate financial or operational consequences but rarely remove technical exposure.

Example: Document the allocated consequences and provider responsibilities while retaining ownership of the technical exposure and residual risk.

Counterexample: Document the deferred item as security debt or a suppression and treat that label as indefinite acceptance of the identified exposure. | Use a temporary mitigation while omitting an owner, expiry, review trigger, permanent fix, or validation of comparable risk reduction. | Rank or close the risk from the raw severity, ticket status, or release date without considering reachability, impact, and evidence.

Limitations: Outsourcing implementation does not outsource accountability.

Tradeoffs: Confirm retained responsibilities and residual risk.

Risk acceptance

Acceptance is a documented decision by an authorized risk owner to tolerate residual risk for a defined scope and period.

Example: Have the authorized risk owner accept a defined residual exposure for a limited period with rationale, compensating controls, expiry, and review triggers.

Counterexample: Transfer financial consequences to a provider while treating the organization no longer retains technical responsibility or residual risk. | Label residual exposure that cannot be removed before release as security debt or a suppression and treat that label as indefinite risk acceptance. | Adopt a temporary mitigation without an owner, expiry, review trigger, permanent fix, or validation of comparable risk reduction.

Limitations: A backlog entry or ignored finding is not risk acceptance.

Tradeoffs: Include rationale, compensating controls, expiration, and review triggers.

Remediation prioritization

Prioritize using exploitability, impact, exposure, asset criticality, reachability, data sensitivity, control coverage, and remediation cost.

Example: Prioritize using reachability, exploitability, impact, exposure, criticality, data sensitivity, existing controls, and remediation cost rather than raw severity alone.

Counterexample: Rely on a temporary mitigation while omitting an owner, expiry, review trigger, permanent remediation or evidence that the temporary control provides comparable protection. | Allocate financial consequences to a provider and assume the organization no longer retains technical responsibility or residual risk. | Label findings with different reachability and business impact as security debt or a suppression and treat that label as indefinite risk acceptance.

Limitations: Low CVSS does not always mean low business risk.

Tradeoffs: Use contextual risk rather than raw severity alone.

Root-cause remediation

Fix the design, coding pattern, library, framework configuration, or process that creates repeated weaknesses, not only individual symptoms.

Example: Correct the repeated coding pattern, framework setting, library, design assumption, or process that generates the entire weakness class.

Counterexample: Choose a temporary mitigation while omitting an owner, expiry, review trigger, a durable fix and validation that residual exposure is acceptably reduced. | Allow the developer, to scanner, supplier, or remediation analyst accept the residual business exposure while omitting the accountable owner. | Let a developer or scanner accept the business risk associated with a repeated insecure coding pattern without an authorized risk owner.

Limitations: Closing one instance does not eliminate a recurring weakness class.

Tradeoffs: Use systemic fixes and regression prevention.

Compensating mitigation

When direct remediation is delayed, temporary controls may reduce exposure, such as disabling a route, narrowing access, adding monitoring, or isolating the component.

Example: Apply a bounded temporary control with an owner and expiry while tracking the permanent fix so mitigation does not become silent debt.

Counterexample: Configure the risk priority from the raw severity, ticket status, or release date without considering reachability, impact, and evidence. | Call the deferred item security debt or a suppression and treat that label as indefinite acceptance of the identified exposure. | Label an alternative safeguard while the preferred control is unavailable as security debt or a suppression and treat that label as indefinite risk acceptance.

Limitations: Temporary mitigation should not silently become permanent debt.

Tradeoffs: Set expiry and track permanent remediation.

Security debt

Security debt is deferred weakness or control work that accumulates future cost and risk.

Example: Record the deferred work with its owner, rationale, exposure, compensating controls, repayment plan, and review trigger.

Counterexample: Call the deferred item deferred authentication and logging work or a suppression and treat that label as indefinite acceptance of the identified exposure. | Close one instance of deferred authentication and logging work without correcting the recurring root cause or checking related variants. | Close the risk from the raw severity, ticket status, or release date without assessing exploitability, business impact, exposure, and supporting evidence.

Limitations: Calling something debt does not authorize indefinite acceptance.

Tradeoffs: Record owner, rationale, exposure, and repayment plan.

Risk closure criteria

Close a risk only when remediation, accepted residual risk, avoidance, or approved transfer has evidence and traceability.

Example: Close the risk only after evidence supports remediation, avoidance, approved transfer, or authorized residual-risk acceptance across affected variants and versions.

Counterexample: Transfer financial consequences for a risk ticket proposed for closure and assume the organization retains no technical responsibility or residual risk. | Close one instance of a risk ticket proposed for closure without correcting the recurring root cause or checking related variants. | Label a risk ticket proposed for closure as security debt or a suppression and treat that label as indefinite risk acceptance.

Limitations: Closing a ticket because a release shipped is not risk closure.

Tradeoffs: Confirm related findings, variants, and affected versions.

Risk exception expiration

Exceptions and acceptances should expire or be reviewed when time, exposure, threat, ownership, or system context changes.

Example: Set an expiration or reassessment trigger for changes in time, exposure, threat, ownership, or system context, blocking silent renewal.

Counterexample: Impose a temporary mitigation without ownership, expiration, review conditions, permanent remediation, or evidence of equivalent protection. | Let a developer or scanner accept the business risk associated with an exception after exposure or ownership changes without an authorized risk owner. | Transfer financial consequences for an exception after exposure or ownership changes and assume the organization retains no technical responsibility or residual risk.

Limitations: Permanent exceptions undermine control baselines.

Tradeoffs: Automate reminders and block silent renewal.

Risk communication

Communicate technical details in business terms including affected assets, scenarios, likelihood, impact, options, and residual risk.

Example: Translate the technical weakness into affected assets, attack scenario, likelihood, impact, options, and residual risk for the accountable decision maker.

Counterexample: Schedule or close the risk from the raw severity, ticket status, or release date without evaluating whether the issue is reachable, consequential, and actually resolved. | Label the deferred item security debt or a suppression and use the label to justify leaving the exposure unresolved indefinitely. | Label technical findings presented to a business risk owner as security debt or a suppression and treat that label as indefinite risk acceptance.

Limitations: Technical jargon without decision context impairs governance.

Tradeoffs: Tailor information to the decision maker.

Evaluate and integrate components

Components must be evaluated for security, compatibility, provenance, supportability, privilege, data access, failure behavior, and integration assumptions before use.

Example: Evaluate the component’s provenance, support, privilege, data use, failure behavior, compatibility, and integration assumptions before granting authority.

Counterexample: Apply a wrapper or fallback that exposes unsafe primitives, bypasses authorization, or assumes it can repair unsupported or malicious behavior. | Check only direct manifest entries and ignore the resolved transitive graph, packaged code, plugins, and runtime-loaded dependencies. | Treat individual component test results as proof that identity propagation, data transformation, shared controls, and end-to-end failure are secure.

Limitations: A secure component can create an insecure system integration.

Tradeoffs: Integration security depends on both the component and how it is connected.

Systems-of-systems integration

Systems-of-systems integration connects independently managed systems with distinct identities, policies, lifecycles, and risk owners.

Example: Define identities, policy ownership, data use, failure handling, monitoring, and responsibilities across independently managed systems.

Counterexample: Consider individual component test results as proof that identity propagation, data transformation, shared controls, and end-to-end failure are secure. | Use a wrapper or fallback that exposes unsafe primitives, bypasses authorization, or assumes it can repair unsupported or malicious behavior. | Give the library the host process’s full filesystem, network, identity, and data authority because it cannot run independently.

Limitations: Network connectivity does not establish a trust contract.

Tradeoffs: Make trust assumptions and responsibilities explicit.

Trust contracts

A trust contract documents identities, authentication, authorization, data use, control expectations, failure handling, monitoring, and responsibilities between systems.

Example: Document and enforce shared identity, authorization, data-use, monitoring, and failure responsibilities between the systems.

Counterexample: Regard individual component test results as proof that identity propagation, data transformation, shared controls, and end-to-end failure are secure. | Select the component because it is popular, certified, signed, or has no known CVE, and omit integration-specific review of the integrated component. | Examine only direct manifest entries and ignore the resolved transitive graph, packaged code, plugins, and runtime-loaded dependencies.

Limitations: A legal contract alone does not technically enforce trust.

Tradeoffs: Treat contract changes as security-relevant changes.

Security testing for integration

Integrated behavior must be tested across interfaces, identity propagation, data transformation, failure paths, and shared controls.

Example: Test identity propagation, transformations, failure paths, and shared controls across the composed system instead of combining component certificates.

Counterexample: Review only direct manifest entries and ignore the resolved transitive graph, packaged code, plugins, and runtime-loaded dependencies. | Assign the library the host process’s full filesystem, network, identity, and data authority because it cannot run independently. | Rely on a wrapper or fallback that exposes unsafe primitives, bypasses authorization, or assumes it can repair unsupported or malicious behavior.

Limitations: Individual component certification does not prove integration security.

Tradeoffs: Test the composed system rather than assuming component test results combine.

Integration security analysis

Analyze end-to-end data flows, trust boundaries, privilege accumulation, protocol translation, error handling, and emergent behavior.

Example: Review the end-to-end flow for trust boundaries, privilege accumulation, protocol translation, errors, and emergent attack paths.

Counterexample: Grant the library the host process’s full filesystem, network, identity, and data authority because it cannot run independently. | Approve end-to-end flows and privilege accumulation from popularity, certification, signing, or the absence of known CVEs without integration-specific review. | Inspect only direct manifest entries and ignore the resolved transitive graph, packaged code, plugins, and runtime-loaded dependencies.

Limitations: Pairwise interface analysis can miss system-wide attack paths.

Tradeoffs: Review the complete request and data lifecycle.

Third-party code and open-source libraries

Third-party code must be integrated with known provenance, license, maintenance status, vulnerability visibility, minimal privilege, and controlled updates.

Example: Select a supported, well-scoped dependency with known provenance, license, ownership, vulnerability visibility, minimal privilege, and controlled updates.

Counterexample: Depend on a wrapper or fallback that exposes unsafe primitives, bypasses authorization, or assumes it can repair unsupported or malicious behavior. | Grant an open-source library selected for a privileged service the host process’s full filesystem, network, identity, and data authority. | Use a wrapper around an open-source library selected for a privileged service that exposes unsafe primitives or assumes it can repair unsupported or malicious behavior.

Limitations: Popularity is not proof of security.

Tradeoffs: Prefer supported, well-scoped components with clear ownership.

Software composition analysis

SCA inventories dependencies and identifies known vulnerabilities, licenses, versions, and dependency relationships.

Example: Analyze the resolved dependency graph, including versions, licenses, known vulnerabilities, and update status.

Counterexample: Inspect only direct dependencies for the resolved direct and transitive dependency graph and omit resolved transitive code, plugins, runtime loading, and packaged artifacts. | Adopt a wrapper or fallback while still exposing unsafe primitives, bypassing authorization, and masking unsupported or malicious behavior. | Allocate the library the host process’s full filesystem, network, identity, and data authority because it cannot run independently.

Limitations: SCA does not detect every unknown vulnerability or insecure use.

Tradeoffs: Use lockfiles, resolved dependency graphs, and continuous updates.

Direct and transitive dependencies

Transitive dependencies may introduce code and risk without being explicitly selected by the application team.

Example: Inspect the complete resolved graph and remove or govern transitive packages that were not explicitly selected but still execute or ship.

Counterexample: Keep dependencies introduced indirectly after end of support because no public vulnerability has yet been reported. | Choose the component because it is popular, certified, signed, or has no known CVE, and omit integration-specific review of the integrated component. | Rely on individual component results for dependencies introduced indirectly without testing identity propagation, transformations, shared controls, and failure paths.

Limitations: A small list of direct dependencies can still produce a large attack surface.

Tradeoffs: Analyze the resolved dependency graph, not only manifest entries.

Dependency pinning and lockfiles

Pinning and lockfiles improve reproducibility and control unexpected version changes.

Example: Use a reviewed lockfile for reproducibility and provenance, with an active update process so vulnerable versions do not remain frozen.

Counterexample: Approve a lockfile controlling exact versions from popularity, certification, signing, or the absence of known CVEs without integration-specific review. | Permit the library the host process’s full filesystem, network, identity, and data authority because it cannot run independently. | Employ a wrapper or fallback that preserves dangerous interfaces and cannot contain fundamentally unsupported or hostile behavior.

Limitations: Pinning alone does not establish provenance.

Tradeoffs: Maintain an update process so pinning does not freeze vulnerable versions.

Dependency update strategy

Updates require security review, compatibility testing, release notes, provenance validation, and rollback planning.

Example: Validate provenance, release notes, compatibility, security impact, and rollback before updating, prioritizing supported versions and fixes.

Counterexample: Allow the library the host process’s full authority instead of isolating its required filesystem, network, identity, and data access. | Rely on individual component results for a security update from a supported component without testing identity propagation, transformations, shared controls, and failure paths. | Keep a security update from a supported component after end of support because no public vulnerability has yet been reported.

Limitations: Automatic updates without validation can introduce supply-chain or compatibility risk.

Tradeoffs: Prioritize supported versions and security fixes.

Component minimization

Remove unused dependencies, features, plugins, and transitive packages to reduce attack surface and maintenance burden.

Example: Remove unused packages, plugins, features, and transitive code from the shipped artifact after confirming that required controls remain intact.

Counterexample: Keep unused plugins and transitive packages after end of support because no public vulnerability has yet been reported. | Rely on individual component results for unused plugins and transitive packages without testing identity propagation, transformations, shared controls, and failure paths. | Treat individual component test results as proof that identity propagation, data transformation, shared controls, and end-to-end failure are secure.

Limitations: An unused dependency can still be exploitable if it is packaged or loaded.

Tradeoffs: Use minimal variants and verify that removal does not break security controls.

Component wrapper and facade

A narrow wrapper can centralize validation, error handling, policy, and version adaptation around a third-party component.

Example: Expose only a narrow safe facade that centralizes validation, errors, policy, and version adaptation without presenting unsafe underlying primitives.

Counterexample: View individual component test results as evidence that the composed identity, transformation, control, and failure paths are secure. | Keep a narrow facade around a third-party library after end of support because no public vulnerability has yet been reported. | Enable the library unrestricted host privileges on the assumption that a library cannot be constrained separately.

Limitations: A wrapper cannot repair fundamental malicious behavior or unsupported software.

Tradeoffs: Keep the wrapper small and avoid exposing unsafe primitives.

Component privilege and permissions

Grant components only the filesystem, network, process, identity, and data access required for their role.

Example: Constrain the component’s filesystem, network, process, identity, and data authority, isolating it when complexity or trust warrants it.

Counterexample: Presume individual component test results without testing the security properties that emerge only after the components are connected. | Adopt the component because it is popular, certified, signed, or has no known CVE, and omit integration-specific review of the integrated component. | Inspect only direct dependencies for filesystem, network, process, and data access granted to a component and omit resolved transitive code, plugins, runtime loading, and packaged artifacts.

Limitations: A library executes with the host process’s authority unless constrained.

Tradeoffs: Isolate untrusted or complex components.

Component failure isolation

Use timeouts, circuit breakers, process isolation, queue boundaries, and fallback logic to contain component failure.

Example: Use timeouts, circuit breakers, process or queue isolation, and a fallback that preserves authorization, validation, and data consistency.

Counterexample: Verify only direct manifest entries and ignore the resolved transitive graph, packaged code, plugins, and runtime-loaded dependencies. | Inspect only direct dependencies for timeouts, circuit breakers, and process boundaries and omit resolved transitive code, plugins, runtime loading, and packaged artifacts. | Choose a wrapper or fallback while still exposing unsafe primitives, bypassing authorization, and masking unsupported or malicious behavior.

Limitations: Fallback must not bypass authorization or validation.

Tradeoffs: Define secure degradation and data-consistency behavior.

Component data-handling review

Assess what data a component receives, stores, logs, transmits, or uses for telemetry and model training.

Example: Determine what data the component receives, stores, logs, transmits, or uses for telemetry or training, then disable unnecessary collection.

Counterexample: Rely on individual component results for telemetry, storage, and model-training data used by a component without testing identity propagation, transformations, shared controls, and failure paths. | Approve telemetry, storage, and model-training data used by a component from popularity, certification, signing, or the absence of known CVEs without integration-specific review. | Grant telemetry, storage, and model-training data used by a component the host process’s full filesystem, network, identity, and data authority.

Limitations: A software license does not necessarily disclose all runtime data flows.

Tradeoffs: Minimize data and disable unnecessary collection.

End-of-life and supportability

A component nearing end of support creates vulnerability, compatibility, and remediation risk.

Example: Track support dates and establish a replacement plan because the absence of a known CVE does not make unsupported code safe.

Counterexample: Rely on individual component results for an unsupported dependency nearing retirement without testing identity propagation, transformations, shared controls, and failure paths. | Review solely direct manifest entries while omitting resolved transitive packages, bundled code, plugins, and dynamically loaded modules. | Grant an unsupported dependency nearing retirement the host process’s full filesystem, network, identity, and data authority.

Limitations: No known CVE does not make unsupported software safe.

Tradeoffs: Track support dates and replacement plans.

AI and generated-code component provenance

AI-generated snippets and model-produced dependencies require provenance, review, licensing awareness, secret scanning, and security analysis before integration. 5.6 Apply Security During the Build Process.

Example: Treat the generated snippet and dependency proposal as untrusted input requiring provenance, license review, secret scanning, security analysis, human review, and traceability.

Counterexample: Grant AI-generated snippets and suggested dependencies the host process’s full filesystem, network, identity, and data authority. | Approve AI-generated snippets and suggested dependencies from popularity, certification, signing, or the absence of known CVEs without integration-specific review. | Inspect solely direct manifest entries without examining the dependency graph that is actually packaged or loaded at runtime.

Limitations: AI confidence or plausible syntax is not provenance evidence.

Tradeoffs: Treat generated code as untrusted third-party-like input until reviewed.

Apply security during the build process

The build must preserve source integrity, apply approved security options, prevent tampering, surface warnings, and produce traceable artifacts.

Example: Protect source and build inputs, apply approved hardening and warnings, prevent tampering, and emit traceable artifacts before release.

Counterexample: Enable one compiler hardening flag and assume it repairs unsafe logic, all memory errors, and incompatible unprotected modules. | Permit untrusted pull-request code to use the release runner, shared cache, signing access, and broad repository or cloud credentials. | Hide an exposed secret in the log and continue using the same token, key, or runner identity without revocation or scope reduction.

Limitations: A secure source tree can produce an insecure artifact through an unsafe build.

Tradeoffs: Build security is part of implementation, not an after-release packaging task.

Anti-tampering techniques

Build-time anti-tampering measures help detect or impede unauthorized modification of code and artifacts.

Example: Select anti-tampering measures for the actual platform threat while retaining controls for vulnerabilities that tamper resistance cannot remove.

Counterexample: Allow untrusted pull-request code to use the release runner, shared cache, signing access, and broad repository or cloud credentials. | Harden the final artifact while leaving workflow definitions, plugins, tools, dependencies, caches, intermediate files, and service connections mutable. | Deploy one compiler hardening flag and assume it repairs unsafe logic, all memory errors, and incompatible unprotected modules.

Limitations: Anti-tampering does not make vulnerabilities unexploitable.

Tradeoffs: Choose techniques according to threat, platform, and operational needs.

Code signing

Code signing binds an artifact’s integrity and publisher identity to a digital signature that can be verified before execution or installation.

Example: Protect the signing key and sign only the approved artifact, using the signature for publisher identity and integrity rather than code-quality assurance.

Counterexample: Conceal an exposed secret in the log and continue using the same token, key, or runner identity while omitting revocation or scope reduction. | Implement one compiler hardening flag and assume it repairs unsafe logic, all memory errors, and incompatible unprotected modules. | Secure the final artifact while leaving workflow definitions, plugins, tools, dependencies, caches, intermediate files, and service connections mutable.

Limitations: A valid signature does not prove the code is free of vulnerabilities.

Tradeoffs: Protect signing keys and sign only approved artifacts.

Obfuscation

Obfuscation transforms code to make analysis or modification more difficult while preserving behavior.

Example: Use obfuscation only to delay analysis or protect intellectual property, not as confidentiality or exploit prevention.

Counterexample: Lock down the final artifact while leaving workflow definitions, plugins, tools, dependencies, caches, intermediate files, and service connections mutable. | Mask an exposed secret in the log and continue using the same token, key, or runner identity without revocation or scope reduction. | Enable untrusted pull-request code to use the release runner, shared cache, signing access, and broad repository or cloud credentials.

Limitations: Obfuscation is not encryption and does not stop determined analysis.

Tradeoffs: Use it as delay or intellectual-property protection, not as a primary security boundary.

Compiler switches

Security-relevant compiler and linker options enable warnings, hardening, runtime checks, memory protections, and safe language modes.

Example: Maintain an approved platform-specific compiler and linker profile that enables warnings, hardening, runtime checks, and safe language modes.

Counterexample: Protect the final artifact while leaving workflow definitions, plugins, tools, dependencies, caches, intermediate files, and service connections mutable. | Regard a valid signature, reproducible output, approved CI product, or generated SBOM as proof that the artifact is vulnerability free and trustworthy. | Apply one compiler hardening flag and assume it repairs unsafe logic, all memory errors, and incompatible unprotected modules.

Limitations: Default compiler settings are not automatically secure.

Tradeoffs: Maintain approved per-platform build profiles.

Stack protection

Stack canaries and related compiler features detect selected stack corruption before control flow is hijacked.

Example: Enable stack canaries around native code as defense in depth alongside memory safety and platform mitigations rather than treating it as complete corruption prevention.

Counterexample: Turn on one compiler hardening flag and assume it repairs unsafe logic, all memory errors, and incompatible unprotected modules. | Trust stack canaries around native code because the CI job succeeded, while workflows, runners, caches, dependencies, and credentials remain mutable or overprivileged. | Filter an exposed secret in the log and continue using the same token, key, or runner identity without revocation or scope reduction.

Limitations: Stack protection does not prevent all memory corruption.

Tradeoffs: Combine with memory safety and platform protections.

Position-independent executables

Position-independent code supports address randomization and reduces predictability of code locations.

Example: Build a compatible position-independent executable and verify that the operating environment actually performs address randomization.

Counterexample: Activate untrusted pull-request code to use the release runner, shared cache, signing access, and broad repository or cloud credentials. | Restrict down the final artifact while leaving workflow definitions, plugins, tools, dependencies, caches, intermediate files, and service connections mutable. | Activate one compiler hardening flag and treat it as a repair for unsafe logic, memory defects, and modules lacking compatible protection.

Limitations: PIE alone does not provide ASLR if the operating environment does not randomize.

Tradeoffs: Use compatible linker and runtime settings.

Control-flow protection compiler options

Compiler instrumentation can enforce return, indirect branch, or call-target constraints on supported platforms.

Example: Enable compatible control-flow instrumentation across relevant code and libraries so partial deployment does not leave unprotected paths.

Counterexample: Screen an exposed secret in the log and continue using the same token, key, or runner identity while omitting revocation or scope reduction. | Turn on one compiler hardening flag while treating it as a repair for unsafe business logic, every memory defect, and modules built without compatible protection. | Mask an exposed build credential for compiler-assisted indirect-branch protections in logs and continue using the same token or signing authority.

Limitations: Partial deployment may leave bypass paths.

Tradeoffs: Ensure all relevant modules and libraries are compatible.

Fortified library calls and bounds checks

Compilers can replace selected unsafe operations with checked variants when sizes are known.

Example: Enable fortified operations and bounds checks where supported while replacing unsafe APIs that the compiler cannot make universally safe.

Counterexample: Obfuscate checked library calls generated by the compiler and rely on the transformation as cryptographic confidentiality. | Redact an exposed secret in the log and continue using the same token, key, or runner identity without revocation or scope reduction. | Turn on untrusted pull-request code to use the release runner, shared cache, signing access, and broad repository or cloud credentials.

Limitations: Compiler checks do not make unsafe APIs universally safe.

Tradeoffs: Treat fortification as defense in depth.

Integer and undefined-behavior checks

Sanitizers and compiler modes can detect overflow, invalid shifts, misalignment, and other undefined behavior during build or test.

Example: Run supported overflow and undefined-behavior checks in CI and selected builds, retaining production-safe controls for behavior not covered by debug sanitizers.

Counterexample: Enable one compiler hardening option for overflow and undefined behavior detected in CI and assume it repairs unsafe logic and every memory defect. | Treat a valid signature, reproducible output, approved CI product, or generated SBOM as proof that the artifact is vulnerability free and trustworthy. | Introduce one compiler hardening flag while treating it as a repair for application-logic flaws, memory corruption, and libraries that lack the same hardening.

Limitations: Debug sanitizers may be unsuitable as the only production defense.

Tradeoffs: Use supported checks in CI and selected production builds where appropriate.

Address compiler warnings

Compiler warnings can reveal type errors, truncation, uninitialized values, unsafe conversions, dead code, and suspicious control flow.

Example: Use high warning levels and treat justified categories as errors, resolving or narrowly documenting exceptions instead of accepting warning debt.

Counterexample: Use one compiler hardening flag and treat it as a repair for unsafe logic, memory defects, and modules lacking compatible protection. | Leave untrusted pull-request code to use a trusted release runner with shared caches, signing authority, and broad repository or cloud tokens. | Redact an exposed secret in the log and continue using the same token, key, or runner identity while omitting revocation or scope reduction.

Limitations: Ignoring all warnings creates noise that hides security-relevant issues.

Tradeoffs: Use high warning levels and treat justified categories as errors.

Warning-as-error policy

A warning-as-error policy prevents new warning debt when toolchain and codebase are sufficiently controlled.

Example: Adopt a tuned warning-as-error baseline with narrow documented exceptions so the policy prevents new debt without making the build unusable.

Counterexample: Allow untrusted pull-request code to use release credentials, signing access, and trusted caches that only approved jobs should access. | Allow untrusted contribution code affecting a tuned warning policy for the codebase to run with release credentials and shared trusted caches. | Sign a tuned warning policy for the codebase and treat the signature as proof that the code is vulnerability-free and trustworthy in intent.

Limitations: Turning every possible warning into an error without tuning can undermine adoption.

Tradeoffs: Allow narrow, documented exceptions for platform or generated-code constraints.

Build reproducibility

Reproducible builds produce equivalent artifacts from the same source, dependencies, configuration, and environment, improving integrity verification.

Example: Control source, dependencies, configuration, timestamps, environment, and tools so equivalent declared inputs produce verifiably equivalent artifacts.

Counterexample: Hide an exposed secret in the log and continue using the same token, key, or runner identity while omitting revocation or scope reduction. | Enable one compiler hardening flag while treating it as a repair for all unsafe logic and memory defects across protected and unprotected modules. | Obfuscate two builds from the same declared inputs and rely on the transformation as cryptographic confidentiality.

Limitations: Reproducibility does not itself prove source correctness.

Tradeoffs: Control timestamps, dependency resolution, and environment inputs.

Hermetic builds

Hermetic builds restrict undeclared network, tool, environment, and filesystem dependencies so outputs depend on explicit inputs.

Example: Use isolated builders with pinned declared inputs and no undeclared network, environment, tool, or filesystem dependencies, while validating those inputs.

Counterexample: Mask an exposed build credential for a build with undeclared network and filesystem dependencies in logs and continue using the same token or signing authority. | Remove an exposed secret in the log and continue using the same token, key, or runner identity while omitting revocation or scope reduction. | Allow untrusted contribution code affecting a build with undeclared network and filesystem dependencies to run with release credentials and shared trusted caches.

Limitations: An isolated build can still consume malicious pinned inputs.

Tradeoffs: Use isolated builders and pinned toolchains.

Build artifact integrity

Hash, sign, and track artifacts with immutable identifiers, provenance, and promotion records.

Example: Hash, sign, and track the exact artifact with immutable identity, provenance, and handoff verification from a trusted channel.

Counterexample: Trust hashes, signatures, immutable identifiers, and promotion records because the CI job succeeded, while workflows, runners, caches, dependencies, and credentials remain mutable or overprivileged. | Consider a valid signature, reproducible output, approved CI product, or generated SBOM as proof that the artifact is vulnerability free and trustworthy. | Activate one compiler hardening flag while treating it as a repair for the underlying logic flaw or memory-safety defects in incompatible modules.

Limitations: A hash from an untrusted channel does not independently establish integrity.

Tradeoffs: Verify artifacts at each handoff.

Build secret protection

Signing keys, repository tokens, package credentials, and deployment secrets must not be embedded in build logs or artifacts.

Example: Use short-lived narrowly scoped credentials and an isolated signing service, preventing secrets from entering logs, artifacts, caches, or untrusted jobs.

Counterexample: Implement one compiler hardening flag while treating it as a repair for every application defect merely because the compiler enabled one mitigation. | Sign signing keys and package credentials used by CI and treat the signature as proof that the code is vulnerability-free and trustworthy in intent. | Allow untrusted contribution code affecting signing keys and package credentials used by CI to run with release credentials and shared trusted caches.

Limitations: Masking log text after exposure does not revoke the secret.

Tradeoffs: Use short-lived credentials and isolated signing services.

Generated files and code

Generated source, schemas, clients, and configuration must be included in review, analysis, provenance, and reproducibility controls.

Example: Pin generators and templates and include generated code, schemas, clients, and configuration in review, analysis, provenance, and reproducibility controls.

Counterexample: Obfuscate generated clients, schemas, and configuration and rely on the transformation as cryptographic confidentiality. | Enable one compiler hardening option for generated clients, schemas, and configuration and assume it repairs unsafe logic and every memory defect. | Deploy one compiler hardening flag while treating it as a repair for unsafe logic, memory corruption, and gaps in modules compiled without the option.

Limitations: Generated code is not automatically trusted.

Tradeoffs: Pin generators and templates.

CI/CD pipeline attack surface

The CI/CD pipeline is a privileged implementation environment that can modify source, dependencies, build configuration, artifacts, signatures, and release metadata. Its workflows, plugins, runners, caches, and service connections therefore form part of the build trust boundary.

Example: Treat workflows, plugins, runners, caches, identities, and service connections as the privileged build boundary with least privilege and protected changes.

Counterexample: Redact an exposed secret in the log and proceed using the same runner credential without revoking it or reducing the replacement identity’s scope. | Use one compiler hardening flag while treating it as a repair for all logic and memory weaknesses throughout the complete artifact. | Freeze down the final artifact while workflows, plugins, tools, dependencies, caches, intermediate artifacts, and service connections remain changeable.

Limitations: Securing the final artifact while leaving the pipeline overprivileged or mutable does not secure the build process.

Tradeoffs: Apply least privilege, protected workflow changes, isolated execution, pinned actions and tools, auditable identities, and controlled artifact handoffs.

Pipeline poisoning and cache contamination

Pipeline poisoning manipulates workflow definitions, build scripts, dependencies, generated files, caches, or intermediate artifacts so that trusted automation produces attacker-controlled output.

Example: Protect workflow definitions and intermediate inputs, isolate caches by trust level, and prevent untrusted contributions from executing with release authority.

Counterexample: Sign shared caches and workflow definitions influenced by untrusted changes and treat the signature as proof that the code is vulnerability-free and trustworthy in intent. | Block an exposed secret in the log instead of revoking the credential and reducing the authority of replacement identities. | Mask an exposed build credential for shared caches and workflow definitions influenced by untrusted changes in logs and continue using the same token or signing authority.

Limitations: A build initiated by an approved CI service is not trustworthy when attacker-controlled inputs can alter privileged execution or shared caches.

Tradeoffs: Protect pipeline definitions as code, review privileged workflow changes, isolate caches between trust levels, verify inputs, and prevent untrusted contributions from running with release authority.

Build-runner identities and secret exposure

Build runners commonly receive repository tokens, package credentials, signing access, cloud identities, or provenance authority. Credentials must be short-lived, narrowly scoped, unavailable to untrusted jobs, and revoked or rotated after suspected exposure.

Example: Separate trusted release runners from untrusted jobs and issue short-lived narrowly scoped tokens unavailable to pull-request code or reusable hosts.

Counterexample: Mask an exposed build credential for tokens and signing access granted to CI jobs in logs and continue using the same token or signing authority. | Treat a valid signature, reproducible output, approved CI product, or generated SBOM as proof that the artifact is vulnerability free and trustworthy. | Enable one compiler hardening flag while treating it as a repair for unsafe logic, every memory error, and incompatible unprotected modules.

Limitations: Log masking, ephemeral runners, or OIDC federation alone does not compensate for excessive permissions or execution of untrusted code in a privileged job.

Tradeoffs: Separate trusted release runners from pull-request or untrusted workloads, restrict token permissions, protect logs and process environments, and avoid persistent secrets on reusable runners.

Secure use of AI-assisted coding

Implementation governance must control how coding assistants receive context, suggest code, select dependencies, and interact with repositories or development tools.

Example: Limit the assistant’s repository, context, dependency, and tool access, and subject every generated change to normal review and build gates.

Counterexample: Reduce latency by removing validation, authorization, tenant isolation, quotas, backpressure, cancellation, and audit from the agent path. | Place secrets and proprietary context in the hidden prompt because ordinary users cannot see the model’s internal instructions. | Accept generated code or dependencies after compilation without provenance, license, secret, security, human, and traceability review.

Limitations: Productivity gains do not justify bypassing review and build gates.

Tradeoffs: Treat AI output as untrusted until reviewed and analyzed.

Defend embedded machine-learning algorithms

Implementation must protect model invocation, preprocessing, postprocessing, model files, feature pipelines, and control logic against manipulation and misuse.

Example: Keep critical authorization and safety enforcement outside probabilistic model output.

Counterexample: Optimize throughput by removing validation, authorization, tenant isolation, quotas, backpressure, cancellation, and audit from the agent path. | Regard the model’s natural-language instruction, confidence, or claim of authorization as the enforcement decision. | Apply a semantic or pattern filter as the only prompt-injection, data-leakage, tool, and authorization control.

Limitations: A model’s accuracy score is not a security control.

Tradeoffs: Keep critical authorization and safety enforcement outside probabilistic model output.

Prompt-injection-aware coding standards

Coding standards for LLM-integrated software must treat prompts, retrieved content, tool output, and model responses as untrusted data across distinct instruction and data channels.

Example: Separate instructions from untrusted data, mediate tools externally, and validate model output before use.

Counterexample: Adopt a semantic or pattern filter as the only prompt-injection, data-leakage, tool, and authorization control. | Integrate generated code or dependencies after compilation without provenance, license, secret, security, human, and traceability review. | Load secrets and proprietary context in the hidden prompt because ordinary users cannot see the model’s internal instructions.

Limitations: Prompt wording alone is not an enforceable security boundary.

Tradeoffs: Use explicit policy, context separation, tool mediation, and output validation.

Provenance of AI-generated code

Generated snippets require source context, license review, dependency verification, security analysis, human review, and traceability to the accepted change.

Example: Record source context and assistant use as required, verify dependencies and licenses, scan secrets, analyze security, and obtain human approval before merge.

Counterexample: Integrate generated code or dependencies after compilation while omitting provenance, license, secret, security, human, and traceability review. | Trust a structured model output for a generated snippet proposed for merge without sink-specific parsing, constraints, and server-side authorization. | Use a semantic or pattern filter as the only prompt-injection, data-leakage, tool, and authorization control.

Limitations: A generated snippet that compiles is not provenance-verified.

Tradeoffs: Record assistant use when organizational policy requires it.

Sanitize inputs sent to LLMs

Inputs to an LLM may contain malicious instructions, sensitive data, encoded content, retrieved documents, or control tokens. Apply data minimization, structural validation, content policy, and trust labeling.

Example: Minimize and structurally validate model input, label trust and provenance, enforce content policy, and account for the downstream model and tool behavior.

Counterexample: Send secrets and proprietary context in the hidden prompt because ordinary users cannot see the model’s internal instructions. | Employ a semantic or pattern filter as the only prompt-injection, data-leakage, tool, and authorization control. | Increase throughput by removing validation, authorization, tenant isolation, quotas, backpressure, cancellation, and audit from the agent path.

Limitations: Traditional allowlists alone cannot fully characterize semantic prompt attacks.

Tradeoffs: Sanitize according to downstream model and tool use, not only character patterns.

NLP-driven semantic validation

AI or NLP classifiers may identify malicious intent, sensitive content, or anomalous instructions that simple filters miss.

Example: Use the semantic classifier as probabilistic detection and require deterministic authorization, tool limits, and policy enforcement for sensitive actions.

Counterexample: Trust a structured model output for a transfer that exceeds ownership or transaction rules without sink-specific parsing, constraints, and server-side authorization. | Keep secrets and proprietary context in the hidden prompt because ordinary users cannot see the model’s internal instructions. | Merge generated code or dependencies for a transfer that exceeds ownership or transaction rules after compilation without provenance, license, secret, security, and human review.

Limitations: A semantic classifier cannot serve as the sole authorization control.

Tradeoffs: Use them as probabilistic defense in depth with deterministic boundaries.

Prompt and data separation

Represent system policy, developer instructions, user content, retrieved data, and tool output in distinct structured channels where the platform supports it.

Example: Place system policy, developer instructions, user data, retrieval, and tool output in distinct structured channels with explicit trust labels.

Counterexample: Raise throughput by removing validation, authorization, tenant isolation, quotas, backpressure, cancellation, and audit from the agent path. | Assume the model’s natural-language instruction, confidence, or claim of authorization as the enforcement decision. | Rely on a semantic or pattern filter as the only prompt-injection, data-leakage, tool, and authorization control.

Limitations: Delimiters alone do not prevent models from following injected instructions.

Tradeoffs: Label trust and provenance explicitly.

Tool-call validation

Validate model-requested tool name, arguments, subject authority, resource scope, transaction limits, and expected state before execution.

Example: Reauthorize every sensitive tool call outside the model, checking the action, arguments, resource, limits, and expected state.

Counterexample: Place secrets or proprietary context for a model-requested financial action in a hidden prompt because ordinary users cannot view it. | Approve generated code or dependencies after compilation without provenance, license, secret, security, human, and traceability review. | Put secrets and proprietary context in the hidden prompt because ordinary users cannot see the model’s internal instructions.

Limitations: The model’s statement that an action is authorized is not evidence.

Tradeoffs: Reauthorize every sensitive action outside the model.

Model output validation

Model output used as code, queries, configuration, HTML, commands, or workflow decisions must be parsed, constrained, encoded, and authorized for the destination sink.

Example: Parse generated code or commands into a typed narrow schema, constrain the sink, encode as needed, and reauthorize the resulting business action.

Counterexample: Accept generated code or dependencies after compilation while omitting provenance, license, secret, security, human, and traceability review. | Merge generated code or dependencies for generated SQL, HTML, commands, and configuration after compilation without provenance, license, secret, security, and human review. | Choose a semantic or pattern filter as a complete substitute for deterministic tool mediation, data protection, and authorization.

Limitations: A JSON schema validates structure, not business authorization or truthfulness.

Tradeoffs: Prefer typed schemas and narrow command sets.

AI-generated dependency suggestions

Suggested packages may be nonexistent, malicious, abandoned, misspelled, or vulnerable. Resolve through approved registries and provenance controls.

Example: Resolve the exact package through approved registries and verify name, version, maintainer, signature, support, and vulnerability status before use.

Counterexample: Position secrets and proprietary context in the hidden prompt on the assumption that hidden model instructions cannot be extracted or influenced. | Increase throughput for a package name proposed by a coding assistant by removing validation, authorization, tenant isolation, quotas, backpressure, and audit. | Maximize throughput by removing validation, authorization, tenant isolation, quotas, backpressure, cancellation, and audit from the agent path.

Limitations: A popular-sounding package name may enable dependency confusion.

Tradeoffs: Verify exact names, versions, maintainers, signatures, and support.

Declarative policies translated to imperative enforcement

AI may assist in translating declarative security policy into runtime code, configuration, or policy-engine rules, but the translation must be constrained, reviewed, tested, and traceable.

Example: Constrain generated enforcement to approved templates, compare it with the source policy, test it, and preserve traceability.

Counterexample: Expand throughput while stripping validation, authorization, tenant isolation, quotas, backpressure, cancellation, and audit from execution. | Store secrets and proprietary context in the hidden prompt because concealed prompt context is treated as a secure secret store. | Authorize generated code or dependencies after compilation while omitting origin, licensing, secret scanning, security analysis, human approval, and change traceability.

Limitations: Generated imperative code must not silently broaden the declarative policy.

Tradeoffs: Use deterministic validation and approved templates around generated enforcement.

Declarative boundaries for AI agents

Explicit policies should restrict tools, data, identities, resources, actions, sequence, rate, and approval thresholds available to autonomous agents.

Example: Enforce allowed tools, identities, data, resources, actions, sequence, rate, and approval thresholds in external policy and execution layers.

Counterexample: Trust a structured model output for tools, data, identities, actions, and approval thresholds for an agent without sink-specific parsing, constraints, and server-side authorization. | Consider the model’s natural-language instruction, confidence, or claim of authorization as the enforcement decision. | Increase throughput for tools, data, identities, actions, and approval thresholds for an agent by removing validation, authorization, tenant isolation, quotas, backpressure, and audit.

Limitations: Natural-language instructions inside the model are not sufficient containment.

Tradeoffs: Enforce boundaries in external policy and execution layers.

High-throughput AI workload safety

Implementation must bound token usage, concurrency, queue depth, retries, memory, tool fan-out, and cost while preserving authorization and auditability.

Example: Apply tenant-aware quotas, bounded concurrency, backpressure, cancellation, and audit without bypassing authorization.

Counterexample: Depend on a semantic or pattern filter without external policy enforcement for tool access, sensitive data, and protected actions. | Merge generated code or dependencies after compilation while omitting provenance, license, secret scanning, security analysis, human review, and traceability. | Retain secrets and proprietary context in the hidden prompt on the assumption that hidden model instructions cannot be extracted or influenced.

Limitations: Throughput optimization must not remove validation or policy checks.

Tradeoffs: Apply quotas, backpressure, cancellation, and tenant isolation.

AI coding assistant data leakage

Source code, secrets, customer data, prompts, and proprietary context may be transmitted to an assistant provider or retained under provider policy.

Example: Apply data-classification and provider-retention rules to the full code and customer context, using approved enterprise settings and minimizing transmitted data.

Counterexample: Merge generated code or dependencies after compilation while omitting provenance, legal review, credential checks, security review, human validation, and traceability. | Merge generated code or dependencies for source code and customer context sent to an assistant provider after compilation without provenance, license, secret, security, and human review. | Deploy a semantic or pattern filter as a complete substitute for deterministic tool mediation, data protection, and authorization.

Limitations: Removing obvious secrets does not eliminate proprietary-data risk.

Tradeoffs: Apply data-classification rules and approved enterprise configurations.

Model and prompt secret handling

System prompts, API keys, model credentials, safety policies, and retrieved secrets require access control and must not be exposed to untrusted model output.

Example: Keep prompts, API keys, model credentials, policies, and retrieved secrets outside untrusted output and minimize any sensitive model context.

Counterexample: Continue secrets and proprietary context in the hidden prompt because concealed prompt context is treated as a secure secret store. | Use a semantic or pattern filter as the solely prompt-injection, data-leakage, tool, and authorization control. | Place secrets or proprietary context for system prompts, model credentials, and retrieved secrets in a hidden prompt because ordinary users cannot view it.

Limitations: A hidden prompt is not a secure secret store.

Tradeoffs: Assume model context may be exfiltrated and minimize sensitive content.

AI implementation logging

Log model version, policy version, tool calls, decisions, validation outcomes, and correlation data while minimizing prompts and personal data.

Example: Log model and policy versions, tool calls, validation outcomes, decisions, and correlation data while minimizing prompts and personal information.

Counterexample: Trust a structured model output for model, policy, tool-call, and validation events without sink-specific parsing, constraints, and server-side authorization. | Increase throughput for model, policy, tool-call, and validation events by removing validation, authorization, tenant isolation, quotas, backpressure, and audit. | Use a semantic filter as the only prompt-injection, data-leakage, tool, and authorization control for model, policy, tool-call, and validation events.

Limitations: Logging full prompts can create a major confidentiality and privacy risk.

Tradeoffs: Design event schemas for investigation and reproducibility.

Signature-based vs. behavior-based (heuristic) malware detection

Signature-based detection matches content against known malware patterns and is fast and low-noise but cannot detect novel or modified (zero-day) threats until a signature exists. Behavior-based (heuristic) detection observes suspicious actions or characteristics to catch unknown malware, at the cost of higher false-positive rates and greater tuning effort. Effective anti-malware controls typically combine both.

Example: Layer signature-based detection for known threats with behavior-based/heuristic detection for novel or modified malware, accepting the added false-positive tuning that heuristic methods require.

Counterexample: Rely on signature-based detection alone and assume it will catch newly modified or zero-day malware variants. | Deploy behavior-based detection without tuning or triage capacity, generating alert fatigue that causes real detections to be ignored. | Treat 'the antivirus is up to date' as sufficient assurance without considering which detection method actually covers the threat in question.