Layer by Layer
Confidence by Practice
Preparing your CISSP domains…
Read knowledge points freely. Practice, saved topics, progress and personal records require sign-in.
403 knowledge points
Embed security requirements, design, implementation, testing, deployment, operations, and improvement throughout the entire SDLC rather than performing a single security check just before release.
Common traps: Treating a security test performed only at the end of the project as a Secure SDLC.
Distinctions: security throughout lifecycle vs end-of-cycle testing
Find security problems early in requirements, design, and coding, where remediation is usually less expensive than after production deployment. Shift-left does not replace production monitoring and operational security.
Common traps: Assuming shift-left means security is performed only in early lifecycle phases.
Distinctions: early prevention vs full-lifecycle security
Use runtime testing, telemetry, monitoring, and postdeployment feedback to validate real security behavior after release, providing the back-end feedback loop of a Secure SDLC.
Distinctions: production feedback complements shift-left
Express identity, authorization, logging, data protection, availability, privacy, and security constraints as verifiable requirements and trace them into design and testing.
Distinctions: requirements define expected security outcomes; tests verify them
Functional requirements describe what the system must do; security requirements describe how it must do so securely, what it must not permit, and what assurance is required.
Common traps: Writing a security requirement only as 'the system must be secure' without verifiable criteria.
Distinctions: functional behavior vs protection/assurance requirements
Define verifiable security conditions for a story, feature, or release, such as prohibiting unauthorized object access or requiring audit records for critical actions.
Distinctions: acceptance criteria are measurable conditions, not vague policy statements
During design and major changes, identify assets, trust boundaries, threats, and mitigations and convert the results into development and testing requirements.
Distinctions: Domain 8 applies threat modeling to software design; Domain 3 holds broader architecture/design principles 8.1 applies threat modeling within software lifecycle decisions; Domain 1 covers threat-modeling concepts/methodologies and Domain 3 secure-design architecture.
Define scenarios from an attacker or unintended-use perspective that the system must reject or handle safely, providing input to security design and testing.
Distinctions: misuse/abuse requirements inform design; Domain 6 tests them
Before implementation, review trust boundaries, privileges, data flows, and critical control placement so architectural root causes are not discovered only during coding.
Perform design-level security review of interfaces, authentication, authorization, error handling, data flow, and failure modes.
Distinctions: design review precedes code review and examines architecture/behavior rather than syntax
Develop team members with additional security skill to help spread standards, reviews, and security decisions, while recognizing that security champions do not replace dedicated AppSec expertise.
Train developers on language, framework, vulnerability patterns, and organizational standards so security defects are prevented before or during coding.
Define required secure-development activities, roles, exceptions, and evidence so projects follow a consistent organizational minimum standard.
Integrate secure-coding rules into IDEs, reviews, pipelines, and release gates instead of merely publishing a development standard.
At design, merge, build, or release stages, use defined risk and quality criteria to decide whether work may proceed. Gates should support formal exceptions rather than hidden bypass.
Common traps: Making every alert from one security tool an absolute release blocker without risk context.
Distinctions: risk-based release gate vs tool-only blocking
Use vulnerability severity, exploitability, asset context, and business risk to determine release blocking or formal exceptions rather than applying an inflexible rule or ignoring findings.
NIST SP 800-218 SSDF provides high-level secure-development practices that can be integrated into different SDLC models to reduce released vulnerabilities, limit the impact of undetected vulnerabilities, and address root causes.
Distinctions: SSDF augments SDLC; it is not a replacement for Agile/Waterfall/DevOps
Prepare the organization by establishing people, processes, tools, policy, and security requirements needed for sustained secure development.
Protect source code, builds, releases, and software integrity to reduce unauthorized modification and supply-chain tampering.
Use secure practices across requirements, design, coding, building, and testing to reduce weaknesses in the software itself.
Continuously identify, validate, and remediate vulnerabilities in released software and feed root causes back into development practices to prevent recurrence.
Adapt security activities to the development methodology actually used by the project rather than assuming one methodology is inherently secure or insecure.
Waterfall moves through relatively sequential phases such as requirements, design, implementation, testing, and deployment. Phase gates are clear, but late requirement changes and defect feedback can be costly.
Common traps: Assuming Waterfall cannot include iteration or security activities.
Distinctions: phase-oriented planning vs iterative Agile delivery
Agile uses short iterations, continuous feedback, and incremental delivery. Security requirements must enter the backlog, Definition of Done, and each iteration.
Common traps: Interpreting Agile as meaning no documentation or no controls.
Distinctions: iterative delivery does not remove governance/security requirements
Treat threats, security stories, technical/security debt, and remediation as schedulable backlog items rather than placing them in a separate list that is perpetually deferred.
Express a security requirement in terms of user/system value and verifiable conditions for Agile work, while recognizing that not every architectural security requirement can be captured by one story.
Include required reviews, tests, dependency checks, and security acceptance criteria in the Definition of Done so functional completion does not imply unverified security.
Synchronize security design, testing, and remediation with normal development iterations rather than making a separate 'security sprint' the default model.
DevOps uses development/operations collaboration, automation, and fast feedback to improve delivery speed. DevOps itself does not automatically include sufficient security practices.
Common traps: DevOps=DevSecOps
Distinctions: DevOps collaboration/automation vs explicit security integration
DevSecOps embeds security people, controls, and automation into DevOps workflows so risk is addressed continuously in pipelines and team decisions.
Common traps: Treating DevSecOps as merely purchasing a scanning tool.
Distinctions: security integrated into people/process/tooling, not just automated scanning
DevOps emphasizes development/operations collaboration and automation; DevSecOps explicitly integrates security responsibility, testing, policy, and feedback into the same delivery flow.
Feed scanning, review, runtime, and incident findings rapidly back to development teams and backlogs to shorten security-defect remediation cycles.
SAFe scales Agile coordination and planning in large organizations. CISSP focuses on integrating security requirements across program and portfolio workflows rather than memorizing SAFe role details.
Common traps: Memorizing extensive SAFe-specific roles and ceremonies merely because SAFe is named as an official example.
Distinctions: SAFe is explicitly named in the CISSP outline, but CISSP depth is the integration of security into scaled Agile governance—not SAFe-framework certification detail.
Deliver functionality in increments, with each increment satisfying applicable security acceptance and regression requirements.
Iterative development repeatedly designs, implements, evaluates, and improves. Security threat models and requirements should evolve with those iterations.
Prototypes often sacrifice hardening for speed. If a prototype evolves into production, reassess it rather than inheriting temporary security assumptions.
Rapid prototyping and user feedback can shorten development cycles, but security requirements and testing should not be omitted for speed.
A maturity model evaluates how institutionalized and capable a software-security process is and provides a path for improvement. High process maturity does not mean a specific application has no vulnerabilities.
CMM/CMMI-style models assess process capability and institutional maturity. CISSP emphasizes understanding maturity improvement rather than memorizing detailed maturity-level names.
OWASP SAMM assesses and improves organizational software-security practices across Governance, Design, Implementation, Verification, and Operations.
Distinctions: SAMM is software-security maturity; not an application vulnerability scanner
Use current practices, target maturity, and gaps to build an improvement roadmap tailored to organizational risk rather than blindly pursuing the highest maturity level.
Compliance asks whether defined requirements are met; maturity reflects process capability and continuous-improvement strength. Neither substitutes for the other.
After release, continue patching, dependency updates, logging, configuration, support, and vulnerability response. The security lifecycle does not end at deployment.
Distinctions: Domain 8 maintains software; Domain 7 performs broader operational security 8.1 keeps software security responsibilities active after release; Domain 7 performs broader operational security, patching and incident operations.
Maintain security of released software as dependencies, vulnerabilities, certificates, runtime conditions, and configuration change.
Design and implementation compromises made for speed accumulate future maintenance cost. Security-related technical debt can expand attack surface and remediation complexity.
Deferred security design, dependency, and control weaknesses become cumulative risk and should have an explicit owner and priority rather than becoming permanently accepted.
At product end of life, stop relying on unsupported components, notify users, handle data and dependencies, and avoid continuing to release versions that cannot be maintained securely.
Source-code, dependency, pipeline, configuration, and release changes should be reviewed, tested, approved, and recorded. Broader operational change-management processes belong to Domain 7.
Distinctions: Domain 8 controls software-development changes; Domain 7 governs production operational change 8.1 integrates change control into software development lifecycle; 8.2 Software Configuration Management tracks software baselines/versions; Domain 7 governs operational production change.
Require peer/security review before code enters a protected branch, especially for logic, authorization, input handling, and other sensitive changes.
Assess whether a software change affects trust boundaries, permissions, data handling, APIs, or security assumptions and adjust the testing scope accordingly.
A critical vulnerability may justify accelerated development and release, but review, build integrity, rollback capability, and post-change review should still be preserved.
Common traps: Assuming an emergency fix may bypass every security control.
An Integrated Product Team combines business, development, architecture, security, testing, operations, and other cross-functional roles so security is not merely a final approval by one team.
Distinctions: cross-functional ownership vs security as separate gatekeeper
Security members provide risk, requirements, and design guidance while development and business roles share responsibility for software risk.
Operations contributes deployment, logging, supportability, and incident feedback so designs account for real production conditions.
The business owner sets business priorities and risk-acceptance boundaries. Development or security teams cannot independently accept major business risk.
A product owner should include security requirements and remediation in product priorities and balance business value, without replacing the formal risk owner's risk-acceptance authority.
Developers are responsible for following secure-coding standards, addressing review findings, and understanding risks in the frameworks and libraries they use. Security is not solely the AppSec team's responsibility.
Testers validate security requirements, negative cases, and regression behavior. Independent assessment depth belongs to Domain 6.
Feed vulnerability root causes back into coding standards, training, architecture, and tooling rather than fixing only the individual bug.
Analyze recurring defect patterns for systemic causes such as unsafe APIs, missing secure library wrappers, or flawed design patterns and improve the development system as a whole.
Before release, confirm required tests, critical findings, dependencies, signing, rollback, and risk exceptions meet defined readiness criteria.
Known risk that cannot be fixed must be accepted through the defined process by an appropriate risk owner, with mitigation and expiration documented rather than silently ignored by developers.
LLM/copilot coding tools can increase speed but may generate insecure implementations, incorrect API calls, or fabricated dependencies and therefore require review and testing.
AI can produce plausible but incorrect security assumptions, library/API usage, or remediation advice. Developers must validate model output rather than treating it as authoritative.
LLMs may reproduce weak input validation, hard-coded secrets, or insecure cryptographic patterns. AI-generated code should receive the same or stronger review and testing as human-written code before entering the repository.
Submitting source code, secrets, or customer data to an external AI coding service may create provider, training, or retention exposure and must follow data-classification and contractual boundaries.
The Spiral model is a risk-driven iterative lifecycle model. Each cycle identifies and reduces major risks based on objectives, alternatives, and constraints, then performs engineering/validation and plans the next cycle. It suits high-risk, complex, or uncertain projects; CISSP focuses on the combination of iteration and explicit risk analysis rather than treating Spiral as repeated Waterfall.
Common traps: Treating Spiral as several Waterfall sequences chained together. Assuming Spiral emphasizes rapid prototyping without explicit risk analysis.
Distinctions: Spiral = risk-driven iterative development; Waterfall is more phase-sequential; Agile is iterative/adaptive but is not defined by Spiral's explicit risk-driven cycle.
Protect the complete software-development chain—developer workstations, languages/toolchains, libraries, repositories, builds, CI/CD, artifacts, and runtime—so compromise of one point does not silently contaminate software.
Use managed developer devices, least privilege, MFA, patching, EDR, and approved tooling to reduce theft of development credentials or source code.
Developers and test environments should not automatically possess production data or production administrator rights. Use segregation and controlled promotion to reduce misuse and supply-chain risk.
Common traps: Allowing developers to retain long-term production administrator access merely for convenience.
Distinctions: environment separation vs deployment workflow
When selecting a programming language, consider memory safety, type system, runtime, ecosystem, and error handling. No language automatically guarantees application security.
A memory-safe language or runtime automatically prevents or greatly reduces classes such as out-of-bounds access and use-after-free, while authorization, logic, and injection flaws can still exist.
Distinctions: memory-safe languages reduce classes of illegal memory access through language/runtime guarantees; memory-unsafe languages require explicit memory-safety discipline and mitigations
Languages that permit raw pointers and manual memory management require stronger bounds checking, compiler hardening, review, and testing.
Distinctions: memory-safe languages reduce classes of illegal memory access through language/runtime guarantees; memory-unsafe languages require explicit memory-safety discipline and mitigations
Type safety restricts invalid operations between incompatible data types and can reduce some bugs, but does not replace input validation or authorization.
Strong typing constrains type operations, while memory safety focuses on illegal memory access. The properties are related but not identical.
A managed runtime can provide memory management, sandboxing, or bytecode verification, but runtime vulnerabilities and application logic flaws still require management.
Native compilation can provide performance and low-level control but requires attention to compiler flags, memory safety, and platform mitigations.
Dynamic execution, shell integration, and package ecosystems in scripting languages can create injection and dependency risk; actual security depends on how the language is used.
Use language and runtime versions that still receive security updates so end-of-life interpreters or compilers do not become unfixable risk.
High-risk capabilities such as eval, unsafe deserialization, and raw pointers should be restricted or wrapped so convenience does not unnecessarily expand attack surface.
Enable appropriate warnings, stack protection, ASLR/PIE support, and secure build flags to reduce some defect impact, while recognizing that compiler controls cannot fix business-logic flaws.
Review high-value compiler warnings and use them as build gates where appropriate. Persistently ignoring warnings can hide real defects.
Third-party libraries bring their code, maintainers, and transitive dependencies into the application's trust boundary and require inventory, version, source, and update management.
Every external package expands the software supply chain and should be evaluated for maintenance status, source, license, vulnerabilities, and necessity.
Packages required by a direct dependency also enter the product even when developers did not select them explicitly, so transitive dependencies carry real risk.
Introduce only libraries and features that are genuinely needed to reduce attack surface, licensing exposure, and patch burden.
Pinning or otherwise controlling resolved dependency versions improves build reproducibility and reduces surprise introduction of malicious or incompatible versions, but requires an ongoing update strategy.
A lock file records resolved dependency versions and often integrity information and should be version-controlled and reviewed for unexpected changes.
Package registries, credentials, namespaces, and installation scripts are supply-chain trust boundaries. Use trusted sources, integrity verification, and least privilege.
Prefer organization-approved or trusted registries and validate publishers or signatures so unknown mirrors and temporary URLs do not enter builds.
Dependency confusion occurs when an attacker publishes a public package with the same name or a preferred version number as an internal package and an incorrectly configured resolver pulls the malicious public package.
Typosquatting packages use names similar to popular libraries to trick users into installation. Dependency review and approved registries reduce the risk.
Compromise of a trusted project's maintainer account can result in malicious releases, so project reputation does not create permanent trust.
Plan migration away from deprecated or unmaintained libraries before a new vulnerability appears and no fix is available.
Understand the security defaults and configuration of framework features such as authentication, CSRF protection, and template escaping so protective features are not disabled or assumed incorrectly.
Organizations can wrap sensitive APIs such as cryptography, logging, or database access with secure defaults so individual developers do not repeatedly reimplement high-risk logic.
Compilers, linters, generators, build tools, and plugins can execute code and should have controlled sources, versions, updates, and permissions.
Build systems execute scripts and handle secrets and artifacts; compromise can contaminate every release, so build tools require least privilege and auditability.
IDE/editor plugins often can access source, filesystems, and tokens. Restrict plugin sources and permissions so arbitrary extensions do not enter controlled environments.
Automatically generated code still requires review, versioning, and security testing and should not be trusted simply because a tool produced it.
Record compiler, builder, plugin, and dependency sources and versions so builds can be reproduced and software-supply-chain tampering investigated.
IDEs handle source code, credentials, and build tools and should be patched, limit plugins, protect tokens, and enable appropriate security-analysis capabilities.
Environment variables, debug configurations, and local files can expose API keys or credentials. Use secret management and avoid committing them to repositories.
IDE linting can flag unsafe APIs, secrets, and weak patterns during coding, but developers must still interpret warnings in context.
Pre-commit checks can run secret scanning, formatting, linting, or lightweight SAST for rapid feedback, while server-side pipelines should independently enforce required controls.
The permissions, configuration, dependencies, sandboxing, and secrets of the real runtime environment determine the production attack surface of application code.
Distinctions: source security and runtime security are complementary
Give each service, process, or container only the operating-system, filesystem, network, and cloud permissions it actually needs to reduce the impact of compromise.
Obtain short-lived runtime credentials from controlled secret stores instead of hard-coding them or embedding them in images or artifacts.
Production configuration should use secure defaults, be version/change controlled, and avoid exposing debug or test functionality.
Runtime sandboxing limits the resources and system calls available to code, reducing post-exploitation capability, while recognizing that the sandbox itself can contain escape vulnerabilities.
Keep runtime platforms, frameworks, and container base images maintained. Detailed patch operations belong to Domain 7.
Continuous Integration frequently merges code and automatically builds/tests it, improving feedback speed. CI security must protect runners, credentials, pipelines, and artifact integrity.
Continuous Delivery automates building and keeps a release deployable, while production release may still require a human or policy approval.
Continuous Deployment automatically releases changes that pass defined criteria into production. The principal distinction from Continuous Delivery is automatic production deployment.
Continuous Delivery keeps software ready to release while production deployment may require approval; Continuous Deployment automatically sends qualifying changes to production.
Common traps: Treating delivery and deployment as synonyms.
The CI/CD pipeline is a high-value software-supply-chain control plane and must protect its configuration, runners, secrets, approvals, artifacts, and logs.
Versioning pipeline definitions as code makes them reviewable and reproducible, but branch protections and controls for privileged workflow changes remain essential.
CI/CD runners execute potentially untrusted build and test code and should be isolated, short-lived, least-privileged, and prevented from sharing sensitive credentials across projects.
Creating a clean ephemeral runner for each job reduces cross-build residue and persistence, while requiring a trusted image and provisioning process.
Pipeline credentials should be least-privileged, scoped to the target environment, kept out of logs, and preferably short-lived rather than long-lived static tokens.
Separate build, test, signing, and deployment privileges so compromise of one job does not provide complete production-release capability.
Use protected deployment environments, approvals, and restricted credentials so ordinary development branches cannot directly obtain production tokens.
After building, protect and validate artifacts with hashes, signatures, and provenance so deployment uses content produced by the approved build process.
Sign packages or images using protected signing keys so consumers can verify publisher and integrity. A valid signature does not prove the software is vulnerability-free.
Record which source, builder, dependencies, and process produced an artifact so the software supply chain can be verified and a release reproduced.
A reproducible build produces the same artifact from the same source and dependencies under controlled conditions, improving tamper detection and supply-chain transparency, although feasibility depends on language and toolchain.
Isolate build jobs from the Internet, other projects, and production credentials where appropriate to limit lateral impact from malicious dependencies or build scripts.
Before deploying a high-risk release, verify testing, findings, signing, and exceptions. Approval should reflect actual risk rather than a ceremonial click.
Log who changed pipelines, approved releases, ran deployments, and accessed secrets so investigations and separation-of-duties reviews have evidence.
Use risk criteria to gate releases based on SAST, SCA, DAST, secret scanning, and related results and provide a formal exception path.
Software Configuration Management controls the versions, changes, state, and traceability of source, build scripts, dependencies, configuration, and release baselines. Domain 7 CM focuses on running-system configuration.
Distinctions: software-development configuration control vs operational system configuration 8.2 SCM manages source/build/configuration baselines and versions; 8.1 addresses lifecycle change integration; Domain 7 configuration/change management governs operational systems.
A software baseline defines the approved source, dependencies, configuration, and build artifacts for a release and supports rebuild, rollback, and audit.
Version control records source/configuration history, authors, and diffs for collaboration and traceability. Repository permissions and branch policy determine much of its security value.
Protect repository identities, permissions, branches, webhooks, tokens, and audit logs to prevent unauthorized source or pipeline changes.
Give developers only the repository and branch permissions needed for their work and manage administrator and bot accounts separately.
Protect main/release branches with required reviews, status checks, optional signed commits, and restrictions on force-push so normal merge controls cannot be bypassed.
Before merge, have appropriate peers review logic, security, and tests; sensitive code can require additional owner approval.
Critical code paths can require review by designated security or business owners so authentication, payment, or pipeline code cannot be modified unilaterally by any developer.
Allowing history rewrites on protected branches weakens audit and review evidence. Restrict force-push to exceptional recovery scenarios.
Cryptographic commit signatures can improve assurance about authorship and integrity, but developer signing keys still require protection and signatures do not replace review.
Repository webhooks can trigger builds/deployments and may carry secrets. Validate their source/signature and restrict privilege so they do not become an uncontrolled pipeline entry point.
Secret scanning detects committed passwords, tokens, and private keys. After discovery, revoke the secret; deleting it only from the current file does not erase historical exposure in the repository.
Critical repositories need backup or replication plus recovery testing so platform failure or malicious deletion does not destroy development capability.
Combine multiple software-security testing methods to find source, dependency, runtime, and interaction defects because no single tool covers every vulnerability class.
Distinctions: 8.2 integrates AppSec testing methods into the development ecosystem; Domain 6 independently assesses/tests controls and interprets testing effectiveness.
SAST analyzes source or bytecode without running the application and supports early and CI testing, but can produce false positives and may have limited framework/business-context understanding.
Common traps: Assuming SAST proves that a reported weakness is actually exploitable.
Distinctions: static code analysis vs runtime behavior
DAST sends requests to a running application and observes behavior from the outside. It sees real runtime exposure but usually lacks source visibility and precise defect location.
Distinctions: black-box runtime testing vs source analysis
SCA identifies third-party/open-source components, versions, licenses, and known vulnerabilities and supports dependency/SBOM management, but does not find every logic flaw in proprietary code.
IAST instruments a running application during testing to observe code/runtime data flows, combining some SAST and DAST advantages while requiring supported runtimes and representative test traffic.
SAST examines static source or bytecode and can run early; DAST tests a running application and more closely reflects an external attack view. The methods are complementary.
Common traps: Treating SAST and DAST as substitutes rather than complementary techniques.
SAST does not require the application to run; IAST uses instrumentation during runtime testing to observe actual execution paths and data flows.
DAST observes application responses externally; IAST adds internal instrumentation that provides code and data-flow context.
SCA focuses on third-party components, versions, and known vulnerabilities; SAST analyzes coding weaknesses in source or bytecode. They answer different questions.
Combine SAST, DAST, SCA, IAST, manual review, fuzzing, and other methods according to risk because every technique has blind spots.
Automated SAST rules may not understand business context and require triage and governed suppression. Persistently ignoring every warning is not a valid strategy.
Tune SAST rules for the language, framework, and historical findings to improve signal, but over-disabling rules can create false negatives.
Authenticated DAST can cover post-login functionality. Use accounts with different roles to test authorization rather than scanning everything only as an administrator.
Active DAST can create or modify data and trigger business functions. Assess scope and safety constraints before running it in production.
IAST agents or instrumentation can affect performance or compatibility and should be used in appropriate test environments with protection for the data they collect.
SCA depends on correct component mapping and current vulnerability intelligence. Stale databases can create false negatives.
An SBOM records software components and dependencies in a release, improving supply-chain transparency, vulnerability response, and acquisition assurance. An SBOM does not prove that the components are secure.
Common traps: Assuming possession of an SBOM proves that software is secure.
Distinctions: inventory/transparency vs vulnerability-free assurance 8.2 creates/maintains SBOM as part of build/development transparency; 8.4 consumes supplier SBOM for acquisition and impact assessment.
Generate an SBOM automatically during the build and bind it to the release so it reflects the actual artifact rather than a stale manual list.
When a vulnerability is disclosed, use the SBOM to identify affected products and versions and support rapid impact analysis and customer communication.
Scan commits and builds for hard-coded secrets and revoke/block them when found. Scanning does not replace secret-lifecycle governance.
Scan IaC templates before deployment for public storage, overly broad IAM, and insecure cloud/network settings, while continuing to monitor the resulting runtime environment.
Scan container images for base-image, package, and configuration risk and combine the results with trusted registries, signing, and runtime protection.
Use automatically generated abnormal inputs to explore parser, memory, and state defects in high-risk interfaces, while recognizing that fuzzing does not replace business-logic testing.
Write repeatable unit security tests for validation, authorization helpers, and security functions so regressions are detected quickly in every build.
Test combinations of services, identities, databases, and queues to validate security assumptions and trust boundaries that emerge only during integration.
After remediating a vulnerability, retain an automated regression test so future changes do not reintroduce the same defect.
Human code review can understand business logic, authorization, and complex data flow that automated tools often miss and should focus on higher-risk code.
Retain tool versions, configurations, results, and their relationship to releases so security-test evidence supports audit and reproducibility.
Embed AI-assisted security testing into CI/CD to find defects in AI-generated code and provide repeatable pre-release feedback, while independently validating AI-generated test output.
Apply the same review, SAST/SCA, and testing requirements to AI-generated or heavily AI-modified code as to human code; tool origin is not a reason for automatic trust.
AI can help generate tests or triage findings, but hallucinations and omissions can create false confidence. Cross-check model results with other tests and evidence.
Determine whether software-security controls and development processes actually reduce risk rather than merely confirming that tools, policies, or test activities exist.
Distinctions: 8.3 evaluates whether the software-security process and controls actually work; Domain 6 conducts broader security-control assessment/testing across the enterprise.
Evaluate whether security requirements, architecture, and controls are designed adequately to address target risks even before long-term operating results are available.
Determine whether reviews, testing, dependency management, and release gates are actually performed consistently over time and produce the intended results.
Support software-security conclusions with code reviews, test results, change logs, SBOMs, build provenance, finding closure, and incident feedback rather than verbal claims.
Map security requirements to design, implementation, testing, and release evidence so important requirements are not lost during development.
Assess whether critical threats, assets, interfaces, and requirements have corresponding controls and verification rather than merely counting test cases.
Use metrics such as defect trends, remediation time, coverage, dependency exposure, and escape rate to observe security performance and define calculation methods consistently.
Normalize vulnerability counts by code size, component, or release to observe trends, while recognizing that different languages and scanner rules limit direct cross-project comparison.
A vulnerability discovered only after release that reasonably could have been caught during development indicates a gap in testing, review, or requirements.
Vulnerability escape rate measures production-discovered defects relative to those found during development and can indicate Secure SDLC effectiveness when classification is consistent.
Repeated occurrence of the same weakness often means the individual instance was fixed without addressing root causes in coding standards, training, libraries, or architecture.
Measure the time from confirmed finding to remediation and validation, stratified by risk so large numbers of low-severity findings do not hide delays on critical issues.
Track whether findings at each risk level are closed within defined remediation SLAs, while recognizing that high compliance does not prove undiscovered vulnerabilities do not exist.
Coverage metrics can show whether critical services, APIs, branches, or requirements were tested. High code coverage does not automatically mean adequate security coverage.
Security-gate pass rate can show pipeline trends, but the metric becomes misleading if teams improve it by weakening rules or abusing exceptions.
Teams may game security metrics by disabling rules, splitting findings, or reducing scan scope. Validate metrics against independent evidence and actual outcomes.
Leading indicators such as review coverage, training completion, dependency age, and threat-model completion can signal process risk before production incidents occur.
Distinctions: leading indicators signal process/risk conditions before outcomes; lagging indicators measure outcomes already observed
Lagging indicators such as production vulnerabilities, incidents, and customer-discovered flaws reflect outcomes that already occurred and are useful for trends but insufficient alone for prevention.
Distinctions: leading indicators signal process/risk conditions before outcomes; lagging indicators measure outcomes already observed
Log and audit changes to source, repositories, pipelines, dependencies, approvals, and deployments so it is traceable who changed what and when.
Repository audit logs should preserve authorship, commits, reviews, merges, and branch events to support investigation of unauthorized or suspicious source changes.
Track changes to CI/CD workflows, runners, secrets, and deployment policy because pipeline changes can affect every release.
Changes to lock files, manifests, and SBOMs should explain added, upgraded, or removed components and reveal unexpected supply-chain changes.
Link each release artifact to source commits, builds, tests, approvals, signatures, and deployments to maintain an end-to-end provenance trail.
Protect software change logs against unauthorized modification and retain them appropriately so a person with release privilege cannot easily erase evidence of their own actions.
Give heightened monitoring to changes affecting authentication, authorization, cryptography, pipelines, dependencies, and security configuration because not every functional diff has equal security risk.
Use branch protection, signed artifacts, provenance, and audit logs to detect changes that bypass review or directly alter a release.
Analyze software risk using threats, weaknesses, assets/data, exposure, and business impact rather than scanner severity alone.
Distinctions: 8.3 applies risk analysis to software-security findings; Domain 1 owns enterprise risk governance and risk acceptance authority.
Technical severity is one input to business risk. Reachability, data sensitivity, user population, compensating controls, and business impact also matter.
Known exploitation, attack complexity, required privilege, and interface reachability affect finding priority. Lack of a public exploit does not mean zero risk.
Evaluate consequences such as data disclosure, fraud, outage, security bypass, regulatory exposure, and customer harm rather than considering only the technical error.
Mitigate software risk by fixing code, updating dependencies, changing design, adding controls, or limiting features, with an accountable owner and validation of effectiveness.
Software remediation directly corrects the root cause in source, dependencies, configuration, or design and uses retesting to confirm closure.
When immediate remediation is not feasible, controls such as a WAF, feature disablement, network restrictions, or additional monitoring can reduce risk, but do not eliminate the root cause.
Residual software risk that cannot reasonably be mitigated must be formally accepted by an appropriate risk owner with scope, rationale, expiration, and review.
Avoid a risk source entirely by discontinuing a high-risk feature, library, or product path, recognizing that avoidance also gives up the associated business capability.
Contracts, insurance, or managed services can transfer portions of financial exposure, but the organization retains governance responsibility and residual security risk.
A release-gate exception should document the finding, risk owner, mitigation, expiration, and planned remediation rather than hiding the issue through permanent suppression.
Mark an AppSec finding as a false positive only after human validation and retain the rationale. Large-scale unsupported suppression weakens detection.
Every security tool has coverage blind spots, so combine multiple methods, manual review, and production feedback to reduce false-negative risk.
Periodically validate scanner and rule effectiveness with known test cases, historical findings, or benchmarks rather than assuming a tool is effective because it is running.
Software changes can break authentication, logging, validation, or security headers, so maintain automated regression tests for critical controls.
Feed incident, WAF/EDR, bug-bounty, and customer findings back into designs, tests, and coding standards.
Authorized external researchers can discover issues missed by internal testing, but a bug-bounty program requires scope, safe-harbor/disclosure terms, and triage and is not required for every organization.
Retain requirements, reviews, test evidence, SBOMs, release provenance, and exceptions so an audit can validate both the process and a specific release.
AI can help summarize code findings and risk, but formal conclusions should be supported by verifiable evidence. Domain 8's explicit AI emphasis is development and CI/CD, not treating AI-generated scores as authoritative.
Assess suppliers, components, maintenance, vulnerabilities, data, identity, and exit risk throughout procurement, integration, and lifecycle. Buying software does not transfer the organization's risk accountability.
Building software gives more design control but creates development responsibility; buying reduces some development burden but adds supplier and supply-chain dependence. Choose according to risk and capability.
Before an RFP or contract, define requirements for secure development, vulnerability disclosure, patching, SBOMs, logging, data, identity, and incident response.
Evaluate whether the supplier has a mature Secure SDLC, review/testing, dependency management, and vulnerability response rather than relying on marketing claims.
Review supplier security capability, incident history, support, subprocessors, certifications, and financial/continuity risk. Certification is only one form of evidence.
Software can be compromised at source, dependency, build, distribution, update, or supplier-access stages, requiring layered software-supply-chain assurance.
Distinctions: 8.4 focuses security impact of acquired software and software supply-chain artifacts; Domain 1 owns enterprise SCRM governance and supplier risk strategy.
Publishers, registries, build services, update servers, signing keys, and distribution channels are all internal or external supply-chain trust boundaries.
Understanding third-party/open-source components and subsuppliers inside a product supports rapid analysis of new vulnerabilities and licensing effects.
An acquisition SBOM improves component transparency and vulnerability response, but does not prove component provenance, absence of vulnerabilities, or that the actual build was not tampered with.
Common traps: Treating an SBOM as a security certification.
Distinctions: component inventory/transparency vs security assurance 8.4 uses supplier SBOM for acquisition/impact analysis; 8.2 generates and binds SBOM to internally built software artifacts.
Missing transitive, runtime, or bundled components can create false assurance. Compare SBOM content with the actual artifact.
Validate that acquired software came from the expected source and build process using signatures, attestations, provenance, and controlled distribution channels.
Verify publisher and artifact integrity before installation or update. A valid software signature does not mean the code itself is secure.
If an attacker obtains a supplier signing key, malicious updates can carry valid signatures. Signing must therefore be combined with key protection, revocation, and supplier incident response.
A secure update mechanism authenticates source, verifies signatures/integrity, prevents downgrade, and distributes through a protected channel so updates do not become a supply-chain entry point.
Compromise of legitimate distribution infrastructure can deliver malicious releases to many customers, so isolate signing keys, monitor update services, and maintain rollback.
Controlled rollback can recover from a defective or insecure supplier update, while anti-rollback controls should prevent attackers from forcing downgrade to a known-vulnerable version.
Before acquisition, understand patch cadence, EOL/EOS, long-term support, and upgrade paths so critical software does not unexpectedly become unsupported.
A mature supplier has a process to receive, validate, remediate, and disclose vulnerability reports, and customers should know the security contact channel and expected response times.
Contracts or SLAs can define critical-vulnerability response and patch timing, but customers still need to verify actual delivery and deployment capability.
Contracts should define conditions, timing, and evidence for notifying customers of security incidents that affect customer data or software.
Software escrow can place source or build materials with a third party for release under conditions such as supplier failure or breach of contract. Escrow does not automatically make the code secure or maintainable.
COTS software is developed and released by a vendor. Customers should manage configuration, patching, support, vulnerabilities, and integration risk.
Commercial software can enable unnecessary services, accounts, or weak defaults. Harden it before production instead of assuming vendor defaults are secure.
Heavy customization can invalidate vendor assumptions, complicate patches, and increase testing cost and should therefore be constrained and documented.
Customers usually cannot fix COTS source directly and therefore depend on vendor patches, mitigations, and support lifecycle.
Without source access, assurance relies more on supplier evidence, testing, and runtime controls, but closed source should not be assumed inherently more or less secure.
Open source permits code review and community collaboration, but security depends on maintenance, governance, dependencies, and release integrity. Open source is not automatically secure.
Source-code visibility alone does not guarantee effective review, timely remediation, or a protected build and release chain.
Common traps: Assuming open source is necessarily more secure simply because many people can read the source.
Public source code does not inherently make software insecure. Mature governance, review, and widespread use can improve defect discovery and remediation.
Assess maintainer count, release cadence, issue response, security policy, and community activity to identify abandonment or single-maintainer risk.
A small number of maintainers with publish/signing privileges are high-value supply-chain targets; account compromise can contaminate trusted packages.
Open-source software often has deep transitive dependencies and needs SCA, SBOMs, and update governance beyond evaluation of direct libraries.
Open-source licenses can create attribution, source-disclosure, or other obligations and require Legal/procurement review. License compliance and software security are different concerns.
An internal fork gives the organization control but also responsibility for tracking upstream security fixes or it will accumulate a patch gap.
A critical dependency without active maintainers may not receive fixes for new vulnerabilities and should be replaced, internally maintained, or constrained.
Any software developed outside the organization introduces supplier, dependency, update, and support risk and should be assessed according to criticality.
Third-party analytics, payment, advertising, or authentication SDKs run within the application's privilege context, may access sensitive data, and expand attack surface.
Plugins often have broad host-application privilege and require controls on source, signatures, scope, and updates.
Use sandboxing, process/network boundaries, or least privilege around partially trusted third-party components to reduce compromise impact.
Acquisition assessment is not a one-time event. Continue tracking vulnerabilities, supplier incidents, EOL, and major ownership or product changes.
A managed software service includes supplier operation of part of the application or infrastructure. Customers need clear responsibilities for controls, administrator access, logging, data, and exit.
Supplier support and administrator accounts should be least-privileged, MFA-protected, approved, and audited instead of remaining as long-lived shared privileged access.
Contracts and architecture should provide customers sufficient logs for monitoring, investigation, and audit rather than discovering during an incident that the needed evidence is unavailable.
Define ownership and processing responsibilities for customer data, metadata, backups, and generated data, including return or destruction at service exit.
Plan data export, identity termination, configuration transfer, replacement services, and secure deletion before exit to reduce vendor lock-in and termination risk.
When assessing SaaS, PaaS, or IaaS, use shared responsibility to identify who owns application, runtime, OS, identity, configuration, and patch security.
Distinctions: 8.4 assesses acquired cloud software/service impact; Domain 3 defines cloud architecture/shared-responsibility concepts.
In SaaS, the provider develops and operates most of the application stack, while the customer commonly retains responsibilities for identity, configuration, data use, and integrations. Exact boundaries depend on the service and contract.
Distinctions: SaaS places more application/platform operation on provider; PaaS leaves customer responsible for its code, dependencies and application configuration SaaS provider manages most application stack; IaaS customer typically manages OS, middleware and application layers
In PaaS, the provider manages more of the runtime/platform, while the customer remains responsible for its code, dependencies, application configuration, and data.
Distinctions: SaaS places more application/platform operation on provider; PaaS leaves customer responsible for its code, dependencies and application configuration PaaS provider manages runtime/platform; IaaS customer typically manages additional OS and middleware layers
In IaaS, the provider manages physical and virtualization infrastructure, while the customer typically manages the OS, middleware, applications, and their configuration.
Distinctions: SaaS provider manages most application stack; IaaS customer typically manages OS, middleware and application layers PaaS provider manages runtime/platform; IaaS customer typically manages additional OS and middleware layers
A marketplace listing or vendor badge does not replace security assessment. Images or templates may contain weak settings, outdated packages, or excessive privileges.
Changes, outages, or weaknesses in external APIs can affect the application and require version management, timeouts, fallback behavior, and contractual controls.
Assess provider isolation, access models, and testing evidence for multi-tenant services. Customers usually cannot directly test the provider's underlying hypervisor.
Acceptance testing should verify contracted security requirements, configuration, integrations, and critical controls rather than only confirming functional delivery.
A supplier penetration-test report is one assurance artifact. Review its scope, date, method, and unresolved findings instead of relying on a simple 'PASS' statement.
ISO, SOC, and similar certifications can support due diligence, but verify scope, period, and the applicable service. Certification does not prove a specific software product has no vulnerabilities.
A supplier statement of 'no known vulnerabilities' reflects only a particular time and knowledge state and does not eliminate the need for ongoing monitoring and customer controls.
If business needs require acquiring software that does not meet a security requirement, an appropriate risk owner should approve the exception with mitigation, expiration, and a replacement plan.
AI/ML frameworks, pretrained packages, and related libraries are part of the software supply chain. Validate source, version, dependencies, and updates to prevent malicious or tampered components from entering products.
Model hijacking at the software layer can occur when an attacker alters model artifacts, loading paths, dependencies, or runtime integration so the application uses an unauthorized or malicious model. Protect provenance, signatures, access, and the deployment chain.
Inference attacks can use application/API queries to infer sensitive training information, model properties, or internal behavior. Software controls should govern access, query patterns, outputs, and monitoring.
Record model source, version, training/transformation, and approval information and verify integrity so unauthorized or substituted models do not enter the software supply chain.
Externally acquired pretrained models can carry unknown training-source, malicious-behavior, licensing, and integrity risk and should be evaluated using third-party software-supply-chain practices.
Turn common weaknesses, safe API usage, error/secret/data handling, and language-specific requirements into actionable coding rules and apply them continuously through reviews and tooling.
Distinctions: 8.5 defines source/API coding rules; Domain 3 owns broader secure architecture/design principles, and Domain 6 independently tests resulting controls.
A standard normally defines mandatory minimum requirements, while a guideline provides recommended practices and implementation guidance. Organizations should make clear which rules permit exceptions.
Different languages have different memory, type, library, and error models, so general secure-coding principles should be supplemented with language-specific rules.
CWE standardizes categories of software weaknesses for tools, training, and root-cause analysis. A CWE is not the identifier for a specific publicly disclosed vulnerability.
CWE describes a class of weakness; CVE identifies a specific publicly disclosed vulnerability instance. A CVE may result from a particular CWE category.
Common traps: Treating a CWE identifier as the identifier of a specific product vulnerability.
The OWASP Top 10 is an awareness resource for major web-application risk categories, not a complete security standard or exhaustive vulnerability list.
Weak input handling, authorization, memory use, cryptography, error handling, or business logic in source code can become exploitable vulnerabilities.
A weakness is a defect class or condition that can create risk; a vulnerability is a specific exploitable weakness that can produce security impact.
Validate type, length, range, format, and business constraints at trusted boundaries and prefer allowlisting valid input. Client-side validation does not replace server-side validation.
All security-relevant validation must be enforced on the trusted server side because attackers can bypass browser or mobile-client validation.
Defining valid formats and values is generally more robust than trying to enumerate every malicious pattern, but correct canonicalization and business rules are still required.
A denylist that blocks only known bad strings is easily bypassed by encoding, case changes, or syntax variants and should not be the sole strategy for complex input validation.
Convert multiple equivalent representations into a consistent canonical form before validation and authorization so encoding or path differences cannot bypass controls.
Validation determines whether input meets requirements and may reject it; sanitization transforms or cleans input. Neither should be confused with context-specific output encoding.
Use the correct encoding when untrusted data is written into HTML, JavaScript, URL, or another output context so the data is interpreted as data rather than executable code.
HTML, attributes, JavaScript, CSS, URLs, and other contexts require different output encoding. There is no single universal escaping function for every context.
When untrusted data is concatenated into SQL, operating-system commands, LDAP filters, templates, or other interpreter statements, an attacker may alter execution semantics.
Directly concatenating user input into SQL can change the query. Prefer parameterized queries or prepared statements rather than manual escaping.
Parameterized queries separate query structure from data so parameter values are not interpreted as SQL syntax, making them a core defense against SQL injection.
A stored procedure reduces injection risk only if it does not internally build dynamic SQL from untrusted input. Merely using a stored procedure is not automatically safe.
Concatenating untrusted input into a shell or operating-system command can lead to arbitrary command execution. Prefer avoiding the shell and use safe APIs with strict parameters.
Improper handling of user input in LDAP filters can alter query logic. Use safe APIs, correct escaping, and validation.
Treating attacker-controlled input as template code or an expression can lead to server- or client-side execution. Keep templates and untrusted data separate.
XSS occurs when untrusted data reaches a browser execution context and runs attacker-controlled script. Use context-aware encoding, safe templating, CSP, and other layered controls.
Stored XSS persists a malicious payload on the server and can affect many users. The core fixes still involve safe output handling plus appropriate input/content processing.
Reflected XSS reflects malicious request data immediately into a response where it executes, often requiring the victim to follow a crafted link.
DOM-based XSS occurs when client-side JavaScript writes untrusted data into a dangerous DOM sink. The server response may not directly contain the final executable payload.
CSRF abuses the browser's automatic inclusion of user credentials to cause an authenticated user to perform an unintended state-changing action. Mitigations include CSRF tokens, SameSite cookies, and reauthentication.
CSRF abuses an existing authenticated browser session to send unwanted requests; XSS executes attacker-controlled script in the trusted origin. XSS can often defeat many CSRF defenses.
Path traversal manipulates paths through sequences such as ../ or encoded variants to reach files outside the intended directory. Canonicalize and constrain access to approved roots or objects.
For file uploads, validate content/type/size, randomize names, isolate storage, prevent execution, and scan malicious content. File-extension checks alone are insufficient.
Unrestricted file upload can let attackers place executable or malicious content that leads to web shells, stored XSS, or resource exhaustion.
SSRF causes the server to make attacker-directed requests to internal, metadata, or other restricted destinations. Restrict schemes, hosts, networks, and access to cloud metadata services.
Unsafe XML external-entity processing can read local files, trigger SSRF, or cause DoS. Disable unneeded external entities and DTD processing.
Dangerous deserialization of untrusted objects can invoke gadget chains or code execution. Prefer safer data formats, allowlist expected types, and protect integrity.
Automatic request-to-object binding can let an attacker set sensitive fields such as isAdmin. Explicitly allowlist fields that clients may modify.
Allowing arbitrary redirect destinations can support phishing or token-flow abuse. Restrict redirects to approved locations.
Untrusted input inserted into HTTP headers can enable response splitting, cache attacks, or control bypass. Use safe APIs and reject control characters.
Unvalidated input in email headers can add recipients or alter message structure. Use proper mail libraries and strict field validation.
Out-of-bounds access, use-after-free, and related memory errors can cause crashes or code execution. Prefer memory-safe languages and use compiler/runtime mitigations where applicable.
Writing past a buffer boundary can overwrite adjacent memory and corrupt control flow. Bounds checking and memory-safe design are the fundamental defenses.
A stack buffer overflow can overwrite return or control data. Stack canaries and ASLR can make exploitation harder but do not eliminate the underlying defect.
A heap overflow writes beyond heap-object boundaries and can corrupt neighboring objects or allocator metadata. Correct bounds and memory handling are still required.
Use-after-free occurs when code continues to use memory after it has been released, allowing reused memory contents to be attacker-influenced and causing memory corruption.
Freeing the same allocation more than once can corrupt allocator state. Safer ownership and memory-management models reduce this class of defect.
Arithmetic that exceeds a type's range can produce incorrect lengths, allocations, or authorization decisions. Check boundaries and use safe arithmetic.
Signed/unsigned conversion errors can turn negative values into very large positive values or invalidate bounds checks, especially in low-level languages.
A one-unit boundary or loop error can cause out-of-bounds access or omit required validation.
Passing attacker input as a format string to printf-style functions can read or write memory. Use a fixed format string and treat input only as data.
A race condition occurs when the order of concurrent access to shared state affects the security result, potentially causing authorization or integrity failures.
A TOCTOU flaw occurs when a resource changes between a security check and its later use, causing a sensitive action to rely on a stale decision.
Improper locking can create deadlocks and availability failures. If attackers can deliberately trigger them, the condition becomes a denial-of-service risk.
Unbounded memory, CPU, thread, connection, or file use can cause denial of service. Apply quotas, timeouts, and bounded workloads.
An attacker can craft input that forces worst-case time or space complexity and causes DoS. Use appropriate algorithms and limit attacker-controlled workload size.
Authentication-flow flaws can bypass login, MFA, account reset, or account state. Prefer mature identity components and test abnormal paths.
Missing server-side authorization on each resource or action can enable horizontal or vertical privilege escalation.
IDOR/BOLA occurs when changing an object identifier lets a caller access another subject's resource. The root cause is missing object-level authorization, not whether the identifier is guessable.
Business-logic vulnerabilities abuse legitimate functions in unintended sequences or combinations to bypass business rules and are often difficult for automated scanners to detect.
High-risk transactions should use nonces, timestamps, idempotency, or server-side state so the same valid request cannot be replayed for repeated effect.
Idempotency keys can prevent retries from duplicating payments, orders, or other actions, but the key must be bound to the correct subject and operation.
Use strong unpredictable session IDs, secure cookies, rotation, timeouts, and server-side invalidation rather than implementing fragile custom session mechanisms.
Regenerate the session identifier after successful authentication or privilege change so an attacker cannot preset and reuse a victim's session.
Use Secure, HttpOnly, and appropriate SameSite attributes for session cookies and constrain domain, path, and lifetime.
Do not hard-code passwords, API keys, or private keys in source. Use secret management and deployment-time identity or secret injection.
Store passwords using a dedicated slow password-hashing scheme with salts rather than reversible encryption or fast general-purpose hashes.
Manually choosing cryptographic modes, IVs, nonces, or implementing cryptography directly is error-prone. Use approved high-level libraries and secure defaults.
Embedding cryptographic keys in source, binaries, or container images makes every deployment share exposed key material and makes rotation difficult. Use key-management services.
Tokens, nonces, and cryptographic key material must use a cryptographically secure random-number generator. Ordinary pseudo-random functions are not suitable for security-sensitive values.
Return only necessary error information to users while recording sufficient diagnostic context internally. Error paths should fail securely and must not bypass authorization.
On exceptions, timeouts, or dependency failure, preserve the protected state by default rather than granting access or disabling validation because an error occurred.
Stack traces, queries, filesystem paths, or secrets in user-facing errors help attackers. Record them only in controlled diagnostic logs.
Catching an error without logging or handling it can hide security failures and inconsistent data. Use explicit error handling and telemetry.
Log authentication events, authorization failures, sensitive changes, and other security-relevant events while avoiding passwords, tokens, and other secrets.
Newlines or control characters in attacker-controlled input can forge log records or disrupt parsing. Use structured logging and encode untrusted fields.
Do not write passwords, tokens, full payment data, or unnecessary PII directly into logs, and review debug logging before production deployment.
Design data collection and processing around minimization, purpose, and retention and avoid collecting unnecessary PII for debugging or analytics.
Use secure random temporary filenames, correct permissions, and atomic creation to avoid predictable filenames, symlink attacks, and residual sensitive data.
Create files and directories with least-privilege ownership and permissions rather than relying on deployment operators to correct insecure defaults later.
Prefer high-level safe APIs and framework protections and avoid deprecated or unsafe functions and custom reimplementation of authentication, cryptography, or parsers.
Deprecated or unsafe APIs may stop receiving security fixes or have safer replacements. Coding standards and linting should guide migration away from them.
New deployments should enable authentication, TLS, logging, and least privilege by default; dangerous features should require explicit opt-in rather than being open by default.
Feature flags can rapidly disable a risky capability, but the flag service and administrative permission require protection and stale flags should be removed.
Disable debug endpoints, test credentials, and developer consoles in production so internal state and bypass functions are not exposed.
Do not leave hidden accounts, magic passwords, or unaudited support/test entries. Legitimate break-glass access should use formal IAM mechanisms.
Review high-risk code changes for input handling, authorization, secrets, cryptography, errors, and business logic using checklists and tools as support rather than focusing only on style.
The author should not be the sole approver of a sensitive change. Critical code can require independent reviewers or owners to enforce separation of duties.
APIs are application trust boundaries and need authentication, authorization, schema/input validation, rate limiting, logging, and secure error handling.
User login and identity authentication can use OpenID Connect (OIDC); OAuth 2.0 is fundamentally an authorization framework, and delegated API access normally uses an OAuth 2.0 access token rather than treating OAuth itself as an authentication protocol. Service-to-service authentication can use mTLS, workload identity, or signed requests. APIs should validate authenticity and applicability according to credential/token type—for example, JWT access-token signature, issuer, audience, expiration, and scope, or trusted validation/introspection for opaque/reference tokens. Do not merely check that a credential/token exists, and do not use an OIDC ID Token as an API access token.
Common traps: Treating OAuth 2.0 as a user-authentication protocol. Using an OIDC ID Token directly as an API access token. Checking only that a token exists without validating issuer, audience, expiry, scope, and other applicability requirements.
Distinctions: OIDC = user authentication/identity layer; OAuth 2.0 = authorization framework; API access is normally authorized with an access token
Enforce authorization for every object and function on the server according to the caller's permissions rather than relying on a hidden UI endpoint.
BOLA occurs when an API fails to verify that the caller is authorized for a specific object, often allowing another user's data to be accessed by changing an ID. It is the API form of the same root authorization issue as IDOR.
BFLA occurs when a lower-privileged caller can invoke an administrative or privileged API function because function-level authorization is missing.
Validate request schemas for JSON, XML, protobuf, and similar formats, including types, required fields, ranges, and unknown-field policy, before malformed or unexpected data reaches business logic.
Limit requests and expensive operations per identity, IP, or token to reduce brute force, enumeration, and resource exhaustion while sizing thresholds for legitimate peaks.
Apply quotas to uploads, query complexity, jobs, and storage so one client cannot exhaust shared resources.
Limit page size and query scope to avoid oversized responses or denial of service and to constrain sensitive bulk extraction.
Bind only explicitly approved writable fields so a client cannot set roles, owners, or security flags through mass assignment.
Manage old API versions and deprecation so endpoints lacking current security controls do not remain indefinitely exposed.
Give consumers a migration period and then retire insecure legacy API versions rather than preserving them permanently for compatibility.
Maintain an inventory of internal and external APIs, owners, versions, and exposure. Unknown shadow APIs cannot be patched, monitored, or deprecated reliably.
An API outside formal inventory and governance may lack authentication, logging, patch management, or ownership and is therefore a shadow API.
An API gateway can centralize authentication, rate limiting, and logging, but backends still require critical authorization checks; the gateway should not be the only security layer.
CORS controls whether a browser permits one origin to read responses from another; it is not server-side authorization. Overly broad allowed origins can expose data.
GraphQL security must address field/object authorization, query depth and complexity, introspection, and batch abuse rather than applying only coarse ACLs to one endpoint.
REST commonly uses HTTP resource and verb patterns, but each resource/action still requires authentication, authorization, and safe input handling.
gRPC uses protobuf and RPC methods and requires protected transport, service identity, method authorization, schema controls, and resource limits.
Webhook receivers should validate signatures/source, freshness, and replay and constrain payloads; webhook senders must also protect secrets and destinations.
For high-value signed API requests, use nonces, timestamps, idempotency, and freshness validation so captured requests cannot simply be replayed.
Use consistent status and error schemas without exposing stacks, SQL, or internal identifiers while retaining useful server-side diagnostic logs.
Log caller, resource, action, result, and correlation ID while avoiding complete tokens, passwords, and sensitive payloads.
Software-defined security expresses and deploys security controls through software, APIs, policy, and automation so controls can be versioned, adjusted dynamically, and applied consistently. It is broader than any single product.
Distinctions: 8.5 concerns security controls expressed and enforced through software/APIs/policy; it is broader than Software-Defined Networking (SDN) in Domain 4.
Policy as code versions executable security or compliance policy and evaluates it automatically in pipelines or runtime, improving consistency and auditability while allowing incorrect policy to propagate quickly.
Security as code versions and automates security configuration, tests, and controls alongside software or infrastructure to reduce manual drift.
Centralized APIs or controllers can change large numbers of controls rapidly, so compromise or automation error can have broad impact. Protect the control plane with strong IAM, review, and rollback.
Automation can reduce manual configuration inconsistency and improve repeatability but still needs testing, version control, and governed exceptions.
Use unit and negative tests for policy allow/deny rules to verify expected resources and boundaries and catch privilege expansion caused by policy changes.
Evaluate IaC before deployment for violations of network, IAM, encryption, tagging, and related policy to implement preventive controls before infrastructure is created.
Software-defined security is the broad concept of implementing security controls through software and APIs; Software-Defined Networking specifically refers to software-based network control/data-plane architecture.
If a legitimate business or technical need prevents compliance with a coding standard, document risk, review, mitigation, and expiration rather than permanently bypassing the rule with a comment or suppression.
Enforce coding rules through training, IDE linting, code review, SAST, and pipeline gates so the standard becomes a continuing control rather than only a document.
Update coding standards as languages, frameworks, vulnerabilities, and organizational architecture evolve and retire outdated guidance.
AI-generated code requires focused review for injection, authorization, secrets, cryptography, and dependencies because fluent syntax does not prove security correctness.
An LLM may recommend nonexistent packages, methods, or incorrect security APIs. Developers should verify official documentation and package provenance so hallucinated references do not lead to malicious typosquatting packages.