(ISC)2 Certified Secure Software Lifecycle Professional (CSSLP) (CSSLP) (CSSLP) — Questions 151–221

Signing the image with a private key and publishing a verifiable attestation binds the artifact to a known builder identity and lets consumers detect any post-build modification. Recording build metadata such as source commit and builder details establishes provenance. Verifying with the public key before deployment ensures only trusted, unaltered images reach production, satisfying both integrity and provenance objectives.

Parameterised queries send SQL code and user data to the database as separate entities, so supplied values are treated purely as data rather than executable statements. This prevents attackers from altering query structure, directly blocking SQL Injection, the vulnerability named in the stem.

The first step should be to assess the actual risk. Not all vulnerabilities in a library affect your application if the vulnerable code is not used. By determining reachability and impact, you can prioritize remediation appropriately. This aligns with risk-based vulnerability management and avoids unnecessary panic or rework.

Non-repudiation requires proof binding an action to a specific identity such that the actor cannot later deny it. Digital signatures provide this through cryptographic keys unique to the signer, verifying origin and integrity, and satisfying the requirement for undeniable attribution of the transaction.

When the verifier accepts alg: none, it treats the token as valid without checking any signature, so an attacker can alter claims such as role or subject and forge arbitrary tokens. This is signature bypass, satisfying the stem's stateless authentication scenario.

A requirement must be verifiable to be useful. 'Secure' is subjective and cannot be measured or tested. Without specific criteria, such as encryption standards or authentication mechanisms, testers cannot determine if the requirement is met. This makes it impossible to validate during development or acceptance testing, leading to ambiguity and potential security gaps.

Open design states that the security of a system should not depend on the secrecy of its design or implementation, but rather on the secrecy of keys or passwords. This aligns with Kerckhoffs's principle. By making the algorithm public and subject to scrutiny, vulnerabilities are more likely to be found and fixed. The scenario directly describes this principle, where security rests on key secrecy, not algorithm secrecy.

Requiring encrypted transport in the SRS removes plaintext credential transmission at its root, addressing the confidentiality breach directly during the security requirements phase. This satisfies the stated priority: the legacy integration currently exposes credentials, so mandating TLS or equivalent is the foundational control before further hardening.

In STRIDE, 'S' denotes Spoofing, which covers threats where an attacker impersonates a legitimate user, service, or system to gain unauthorised access. It is countered through authentication mechanisms that verify claimed identities before trust is granted.

Output encoding ensures that data is safely rendered in the target context. For HTML, encoding special characters like < and > prevents script execution; for SQL, parameterized queries handle encoding. While not strictly input validation, output encoding is a critical complementary control that prevents injection even if malicious input is stored. It is effective because it neutralizes dangerous characters at the point of use.

Automated masking strips session tokens and PII at the pipeline boundary, before log data reaches aggregation storage. This satisfies the stem's secure logging requirement by preventing sensitive values from persisting in a repository with broader access and longer retention than the originating service.

Abuse cases invert legitimate behaviour, so they must derive from system functional requirements: each intended feature, input and workflow defines the misuse paths an attacker could exploit. This grounds abuse scenarios in the actual system scope rather than speculation.

A formal component inventory, such as an SBOM, is foundational for regulatory compliance and incident response. It enables traceability when a new vulnerability is disclosed, allowing the organization to quickly determine exposure. FDA guidance emphasizes software bill of materials and component transparency. Without an accurate inventory, even the best scanning tool cannot provide a complete picture of risk or support post-market surveillance obligations.

HttpOnly prevents client-side scripts from reading session cookies, while Secure restricts transmission to encrypted channels, so reviewing these flags directly exposes cookie theft and interception weaknesses. This inspection targets the exact session management controls the review must assess.

Misuse case scenarios describe how an adversary could abuse a system, expressed in plain business language rather than technical controls. Non-technical stakeholders can reason about these narratives, surfacing security requirements they would struggle to articulate from abstract policy or configuration discussions.

Removing default files and pages eliminates vendor-supplied sample scripts, documentation and administrative interfaces that ship enabled by default. These artefacts frequently expose known paths, version details or unauthenticated functionality, directly satisfying the stem's secure-configuration requirement by reducing the attack surface before any application code is deployed.

Security Champions are developers who receive extra security training and embed security practises within their own teams, translating security requirements into daily engineering work. This satisfies the DevSecOps need to scale security expertise without relying solely on a central security team.

Digital signatures provide non-repudiation by cryptographically binding a signer's private key to the message, so the signer cannot later deny authorship. This directly mitigates STRIDE's Repudiation category, which covers denying performing an action. Verification with the signer's public key proves origin and integrity, satisfying the stem's requirement.

An API Gateway terminates authentication centrally, validating tokens before routing to microservices, which then trust the gateway's assertions. This decouples identity logic from each service, satisfying the centralised-authentication requirement without embedding credentials handling in every microservice.

Recording the action type — for example read, write, delete, or login — establishes what operation occurred, which is essential for reconstructing events during an audit. Without it, log entries show only who and when, leaving the nature of the activity unverifiable and accountability incomplete.

Complete Mediation demands that every access attempt be checked against policy, with no caching of prior decisions. Verifying authorisation on each API request satisfies this by preventing bypass through reused sessions or assumed trust, ensuring no request reaches protected resources unchecked.

HIPAA directly governs the handling of Protected Health Information in the United States, mandating administrative, physical and technical safeguards. Since the application processes PHI, its requirements must be captured during the requirements-gathering phase to ensure compliant data protection controls are designed in from the outset.

IAST instruments runtime execution, so it only observes code paths actually exercised during testing. Unreachable or dormant branches never execute, producing no instrumentation data and therefore no findings. This directly satisfies the stem's constraint: identifying common IAST challenges, since coverage gaps in dead code are an inherent limitation of runtime-based analysis.

A strict CSP with nonces or hashes and no inline script blocks the most common injection vectors that would run attacker code in the page. Combined with in-memory token storage, it addresses both the injection and the credential-theft halves of the threat, which is why it belongs in the design rather than as a later hardening step.

An allowlist-only proxy permits only explicitly approved package names and versions, so a typosquatted dependency is rejected at resolution time regardless of how similar its name appears. This directly blocks accidental inclusion, satisfying the stem's constraint.

AES-256 is a symmetric block cipher providing strong confidentiality for stored data, satisfying the at-rest protection requirement. Its 256-bit key resists brute-force attacks, and it is the standard algorithm for database and volume encryption, unlike hashing or asymmetric ciphers suited to other purposes.

Secure coding training equips developers to avoid introducing vulnerabilities such as injection and cross-site scripting during implementation, directly satisfying the plan's requirement to embed security throughout development. Because most defects originate in code, upskilling the people writing it reduces remediation cost and strengthens the Microsoft Entra ID-protected build pipeline's overall assurance.

Isolating the library in a separate process with least privilege limits the impact of a zero-day exploit. If the parser is compromised, the attacker gains only the privileges of that process, not the entire application. The restricted interface further reduces the attack surface. This is a sandboxing approach that contains the blast radius.

Break-glass access allows authorized clinicians to bypass normal access controls in emergencies, ensuring timely care. Logging and retrospective review maintain accountability and compliance with HIPAA's access control and audit requirements. This requirement balances usability (quick access) with security (audit and review), making it the best solution.

Reviewing SOC 2 and ISO 27001 reports provides independent, standardised assurance over a vendor's controls, satisfying the need for objective evidence rather than self-attestation. This directly addresses the stem's requirement for an essential assessment component, since third-party audits validate security posture against recognised frameworks without relying solely on vendor claims.

Filtering sensitive data before logging prevents credentials, tokens and personal information entering log stores, satisfying the secure logging requirement that records must not become a confidentiality liability. Without this control, logs themselves leak the very data the application protects.

Requiring the client_secret proves the token request originates from the legitimate registered client, not an interceptor holding a stolen code. This client authentication mechanism satisfies the stem by binding the code exchange to a verified identity.

Encryption of service-to-service traffic constrains how the system behaves rather than what function it delivers, so it is a quality attribute, not a functional requirement. It specifies a security characteristic the microservices must exhibit, matching the non-functional category.

A credential vault injects secrets at runtime, so pipeline logs, build scripts and source repositories never contain plaintext keys. This removes long-lived credentials from artefacts and satisfies the secure CI/CD requirement to protect secrets throughout build and deployment.

Integrating automated security testing into the CI/CD pipeline allows security checks to run on every code commit, providing immediate feedback to developers. This continuous approach aligns with DevSecOps principles and enables early detection and remediation of vulnerabilities. It is the most effective way to achieve continuous security testing and early feedback.

Secure vaulting stores application secrets and keys encrypted, with access strictly controlled and audited, so credentials are never exposed in configuration files, repositories or logs. This directly prevents unauthorised disclosure of sensitive data during deployment, satisfying the confidentiality requirement.

Mapping the cardholder data flow traces credit card information from entry through storage, processing and transmission, exposing every system, network segment and third party that touches it. This directly satisfies PCI-DSS scoping, which defines scope by where cardholder data resides or transits, so the highest-security controls land on precisely those components.

The HttpOnly flag blocks JavaScript access to the session cookie, mitigating XSS-based theft, while Secure restricts transmission to HTTPS, preventing interception over cleartext channels. Together they harden the cookie itself, a core session management control.

IDE security linting flags insecure code patterns as developers write them, moving detection to the earliest lifecycle phase. This satisfies Shift-Left by preventing defects from progressing downstream, where remediation costs far more than fixing them at authoring time.

Tampering is one of the six STRIDE categories, covering unauthorised modification of data or code in transit or at rest. It is explicitly defined by the methodology, so it correctly satisfies the stem's requirement to identify categories STRIDE names.

Hardcoded keys sit in source control, readable by anyone with repository access, so the secret is no longer restricted to authorised parties. That exposure breaches confidentiality, the property ensuring information is disclosed only to those permitted to see it.

Embedding security requirements as acceptance criteria ensures they are addressed within the same sprint as the functional work. This approach integrates security into the existing Agile workflow, making security a definition-of-done item. It allows the team to verify security controls before story completion, reducing the risk of accumulating security debt and ensuring continuous security consideration.

IAST tools track data flow from sources to sinks. If the tool does not recognize that input validation or parameterized queries neutralize the taint, it may incorrectly report a vulnerability. This is a common cause of false positives in IAST, especially when the tool's rules are not tailored to the application's frameworks. Proper configuration and rule tuning can reduce these false positives.

A Content Security Policy restricts which script sources the browser will execute, so injected inline or third-party scripts are blocked even when output encoding fails. This defence-in-depth directly mitigates XSS by constraining the rendering context.

A traceability matrix directly maps each identified threat to specific security requirements, ensuring that no threat is left unaddressed. It also provides a mechanism to verify that all requirements have been implemented and tested, which is critical for HIPAA compliance and auditability. This approach systematically closes the loop between risk assessment and requirement definition.

Digital signatures bind the sender's private key to the message, so the signer cannot later deny authorship; this provides non-repudiation, proving origin and integrity to a third party. Confidentiality and authentication alone do not prevent the sender disputing the message.

Sniffing traffic exposes data in transit, so the STRIDE category breached is Information Disclosure. The threat targets confidentiality of the client-server communication channel, not integrity, availability or authentication, making Information Disclosure the matching classification for this eavesdropping scenario.

A false positive occurs when the scanner flags a vulnerability that does not actually exist in the application, wasting remediation effort. This contrasts with a false negative, where a genuine flaw goes undetected, making the reported-but-absent condition the defining characteristic.

An updated contact list with clear escalation paths ensures the right responders are engaged promptly during a live incident, satisfying the stem's requirement for an essential Incident Response action. Defined escalation routes prevent delays and miscommunication, which are common causes of prolonged exposure when deployed software is compromised.

DTOs define an explicit allow-list of bindable properties, so the model binder cannot populate fields absent from the DTO. This directly blocks over-posting of sensitive attributes such as role or isAdmin, satisfying the requirement to prevent Mass Assignment during model binding.

Centralised log aggregation with automated alerting satisfies the operational-lifecycle monitoring requirement by consolidating events from distributed components and triggering real-time responses to security incidents, enabling detection across the deployed application rather than relying on isolated host logs.

Abuse case modelling deliberately examines how an attacker would misuse functionality, exposing entry points such as unvalidated parameters and exposed endpoints. This satisfies the stem's goal of identifying exploitable API entry points, unlike use cases, which describe only intended legitimate behaviour.

MTTR directly quantifies how quickly identified vulnerabilities are fixed, evidencing whether secure SDLC controls actually reduce exposure over successive releases. Unlike one-off counts, it tracks remediation capability across time, satisfying the stem's requirement to measure programme effectiveness longitudinally rather than at a single point.

Addressing flaws during design or coding costs far less than patching deployed systems, because remediation effort and blast radius both grow sharply after release. This directly satisfies the stem's cost constraint: early security requirements prevent expensive rework, unlike controls bolted on post-deployment.

Because the EHR databases and logs were encrypted at rest, destroying the key-encryption keys and wrapped data-encryption keys renders the remaining ciphertext permanently unrecoverable. This cryptographic erasure approach is efficient, auditable, and preserves the hardware for internal reuse. Verifying that only ciphertext remains confirms the sanitization objective for regulated health data was met.

Misuse cases invert the actor's intent, modelling an adversary or hostile insider deliberately abusing legitimate functionality to cause harm. This surfaces abuse and attack scenarios during requirements elicitation, complementing use cases that describe only intended, benign behaviour.

The attestation's value depends on the identity of the signer and the build environment it represents. If an internal runner signs on behalf of upstream, the cryptographic guarantee is only that the internal system produced that statement, not that the upstream maintainer did. An attacker who compromises the internal runner can generate a valid signature for a tampered artifact, and downstream verification will still pass.

Cryptographic hash functions produce a fixed-length digest that changes if any byte of the file alters, so recomputing and comparing the digest detects unauthorised modification. This directly satisfies integrity, which requires data to remain accurate and unaltered, unlike confidentiality (encryption) or availability (redundancy).

Misuse cases are a technique to model negative scenarios where an actor intentionally harms the system or exploits vulnerabilities. They help elicit security requirements by identifying what the system should prevent or detect. This proactive approach ensures that security is considered early in the lifecycle, aligning with CSSLP principles.

A hardened base image strips unnecessary packages, shells, package managers and services, so fewer binaries carry exploitable vulnerabilities. Any compromise gains fewer local tools for privilege escalation or lateral movement, directly reducing the attack surface available to an attacker inside the container.

FIPS 140-3 validation is performed by an accredited laboratory against the standard, so only modules holding a valid certificate satisfy the client's mandate. Selecting validated modules during requirements gathering prevents later redesign when an unvalidated cryptographic library is discovered.

Mutual TLS authenticates both client and server at the transport layer, so a compromised credential or spoofed endpoint still fails the handshake. This adds an independent control layer beyond tokens or gateway checks, satisfying defense in depth by ensuring no single authentication failure grants API access.

Assume breach removes implicit trust in the internal network, so every request is treated as potentially hostile. Designers therefore segment, log and limit blast radius rather than relying on perimeter defence, which is the foundational mindset the Zero Trust model requires before verification and least privilege can operate.

Metrics provide measurable evidence that governance controls actually operate, satisfying the framework's need for continuous oversight and accountability. Without tracked performance data, policy compliance cannot be verified or improved, so this practice underpins the monitoring and reporting obligations central to software security governance.

ORM parameterisation only protects generated queries; developers can still concatenate user input into raw SQL executed through the framework's escape hatch. That unsafe raw query path preserves classic SQL Injection, the residual risk the question asks about.

Incremental scanning analyses only changed files or diffs, cutting scan duration and surfacing findings tied to the developer's own commit. This reduces pipeline delay and noise, directly minimising the developer friction the scenario names, while full scans remain for nightly builds.

Row-level security policies in the database enforce tenant isolation at the data layer, ensuring that every query is automatically filtered by tenant ID. This prevents accidental cross-tenant access even if application code has flaws, because the database itself enforces the boundary. It supports a shared schema and single logical database while maintaining strong isolation.

An SBOM inventories every component and dependency in your software, giving the transparency needed to identify and manage supply-chain risk. This directly satisfies the stem's goal: knowing what you ship lets you rapidly trace vulnerable libraries, verify licences, and respond to upstream compromises without guesswork.

Software Composition Analysis inventories third-party and open-source dependencies, matching them against vulnerability databases to identify known flaws before production. This satisfies the requirement to detect vulnerable components in the build, enabling remediation or version upgrades prior to secure deployment.

Fourth-party risk arises from subcontractors and downstream providers the vendor relies on. Maintaining an inventory of critical fourth-party service providers demonstrates visibility and control beyond direct suppliers, satisfying the mature Vendor Risk Management practice of mapping transitive dependencies.

Storing uploads outside the web root removes the path the web server would use to execute them, while renaming strips the original extension and any embedded executable code trigger. Together these defeat RCE because the server can no longer map the file to a script handler, satisfying the constraint that uploaded content must never be directly executable.