1
Q
Explain CIA triad in the context of CSSLP. define the CIA triad and explain why each element matters to secure software. (Domain 1)
A
Confidentiality prevents unauthorized disclosure; Integrity prevents unauthorized alteration; Availability ensures timely, reliable access. All three must be balanced across the SDLC.
2
Q
Explain Authentication, Authorization, and Accounting and how they relate to accountability. (Domain 1)
A
Authentication confirms identity; Authorization grants permitted actions; Accounting records activity. Together they enable traceable, responsible system use.
3
Q
Explain Non-repudiation in the context of CSSLP. describe non‑repudiation and how a software system can provide it. (Domain 1)
A
It ensures a party cannot deny an action. Achieved via strong identity binding and tamper‑evident logs or signatures with time correlation.
4
Q
Explain Security models overview in the context of CSSLP. differentiate Bell‑LaPadula, Biba, and Clark‑Wilson at a high level. (Domain 1)
A
Bell‑LaPadula prioritizes confidentiality; Biba prioritizes integrity; Clark‑Wilson enforces integrity with well‑formed transactions and separation of duties.
5
Q
Explain Design principles in the context of CSSLP. list and explain the purpose of least privilege and separation of duties. (Domain 1)
A
Least privilege limits permissions to the minimum necessary; separation of duties splits critical tasks to reduce fraud or error.
6
Q
Explain defense‑in‑depth and give a simple example in an application. (Domain 1)
A
Multiple independent controls at different layers; e.g., input validation, parameterized queries, and WAF together against injection.
7
Q
Explain Fail‑safe defaults in the context of CSSLP. define fail‑safe defaults and when they are most important. (Domain 1)
A
Systems should default to deny on failure or uncertainty, critical during errors and outages to avoid unintended access.
8
Q
Explain open design vs. security by obscurity. (Domain 1)
A
Security should not depend on secrecy of design; rely on proven mechanisms and protect secrets like keys, not algorithms.
9
Q
Explain Complete mediation in the context of CSSLP. describe complete mediation in access control. (Domain 1)
A
Every access to every object is checked each time to prevent stale or bypassed authorizations.
10
Q
Explain psychological acceptability and its effect on control bypass. (Domain 1)
A
Usable controls reduce workarounds; security that aligns with user workflow is more likely to be followed.
11
Q
Explain the weakest‑link concept and its implication for testing. (Domain 1)
A
Overall security equals the least secure part, so testing must include low‑visibility components and processes.
12
Q
Explain Risk concepts in the context of CSSLP. define risk, threat, vulnerability, and impact in the software context. (Domain 1)
A
Risk is the potential for loss when a threat exploits a vulnerability causing impact to objectives.
13
Q
Explain Security objectives vs requirements in the context of CSSLP. differentiate security objectives and security requirements. (Domain 1)
A
Objectives express desired protection outcomes; requirements specify verifiable conditions to meet those outcomes.
14
Q
Explain trust vs assurance in software. (Domain 1)
A
Trust is confidence in a component; assurance is evidence that the trust is justified (e.g., process rigor, testing).
15
Q
Explain Secure session management in the context of CSSLP. describe key properties of secure session management. (Domain 1)
A
Strong token entropy, rotation, timeout, binding to context, and invalidation on logout or privilege change.
16
Q
Explain Data states in the context of CSSLP. identify data states and why they matter. (Domain 1)
A
Data at rest, in transit, and in use; each state requires tailored protections within the SDLC.
17
Q
Explain the role of organizational policy in software projects. (Domain 1)
A
Policy defines required behaviors and controls; projects derive standards, procedures, and requirements from it.
18
Q
Explain Threat landscape awareness in the context of CSSLP. describe why understanding the current threat landscape matters to teams. (Domain 1)
A
It informs prioritized requirements, testing focus, and design trade‑offs during planning and sprints.
19
Q
Explain Security vs safety in the context of CSSLP. contrast security with safety in software systems. (Domain 1)
A
Security defends against intentional misuse; safety protects against accidental harm. Some controls serve both.
20
Q
Explain why measuring security outcomes helps in the SDLC. (Domain 1)
A
Metrics reveal trends, validate control effectiveness, and guide improvement activities.
21
Q
Describe CIA triad in the context of CSSLP. define the CIA triad and explain why each element matters to secure software. (Domain 1)
A
Confidentiality prevents unauthorized disclosure; Integrity prevents unauthorized alteration; Availability ensures timely, reliable access. All three must be balanced across the SDLC.
22
Q
Describe AAA in the context of CSSLP. explain Authentication, Authorization, and Accounting and how they relate to accountability. (Domain 1)
A
Authentication confirms identity; Authorization grants permitted actions; Accounting records activity. Together they enable traceable, responsible system use.
23
Q
Describe non‑repudiation and how a software system can provide it. (Domain 1)
A
It ensures a party cannot deny an action. Achieved via strong identity binding and tamper‑evident logs or signatures with time correlation.
24
Q
Describe Security models overview in the context of CSSLP. differentiate Bell‑LaPadula, Biba, and Clark‑Wilson at a high level. (Domain 1)
A
Bell‑LaPadula prioritizes confidentiality; Biba prioritizes integrity; Clark‑Wilson enforces integrity with well‑formed transactions and separation of duties.
25
Describe Design principles in the context of CSSLP. list and explain the purpose of least privilege and separation of duties. (Domain 1)
Least privilege limits permissions to the minimum necessary; separation of duties splits critical tasks to reduce fraud or error.
26
Explain how security requirements are elicited alongside business requirements. (Domain 2)
Use interviews, misuse/abuse cases, threat modeling inputs, and policy review to derive explicit, testable security needs.
27
Explain Quality of requirements in the context of CSSLP. define characteristics of a good security requirement. (Domain 2)
Clear, unambiguous, testable, feasible, consistent, and traceable to objectives and risks.
28
Explain Non‑functional security in the context of CSSLP. describe common non‑functional security requirements. (Domain 2)
Authentication strength, session lifetime, logging coverage, availability targets, and data protection objectives.
29
Explain requirements traceability and why it matters for verification. (Domain 2)
Links from source to design, code, and tests ensure nothing is missed and changes are controlled.
30
Explain Data classification in the context of CSSLP. describe how data classification influences requirements. (Domain 2)
Classification drives access, retention, encryption, and monitoring needs for each data type.
31
Explain how privacy principles translate into software requirements. (Domain 2)
Minimization, consent handling, purpose limitation, and subject rights become explicit stories and acceptance criteria.
32
Explain Abuse cases in the context of CSSLP. define abuse/misuse cases and their value. (Domain 2)
They capture undesired interactions to drive preventative and detective requirements.
33
Explain Acceptance criteria in the context of CSSLP. describe the role of security acceptance criteria in user stories. (Domain 2)
They specify how security will be verified, enabling definition of done for stories with security impact.
34
Explain how to prioritize security requirements. (Domain 2)
Use risk and business impact to sequence delivery while preserving foundational controls early.
35
Explain Ambiguity removal in the context of CSSLP. describe techniques to remove ambiguity in requirements. (Domain 2)
Use glossary, examples, decision tables, and consistent wording templates.
36
Explain mapping high‑level obligations into concrete software requirements. (Domain 2)
Translate obligations into specific behaviors, controls, and evidence artifacts within the product backlog.
37
Explain Third‑party requirements in the context of CSSLP. describe requirements for third‑party components and services. (Domain 2)
Define acceptance criteria for updates, vulnerability response, SLAs, and evidence needed from suppliers.
38
Explain specifying cryptographic requirements without naming algorithms. (Domain 2)
State security properties (e.g., confidentiality, integrity) and key management behaviors to allow agility.
39
Explain Availability in the context of CSSLP. describe expressing availability as a requirement. (Domain 2)
Use measurable uptime targets, RTO/RPO, and graceful‑degradation expectations.
40
Explain the requirements perspective on error/exception handling. (Domain 2)
No sensitive leakage, consistent user messages, and centralized logging for analysis.
41
Explain Input validation in the context of CSSLP. define input validation requirements at a high level. (Domain 2)
Specify canonicalization, whitelisting where possible, length and format checks for all trust boundaries.
42
Explain auditability requirements for software components. (Domain 2)
Define who/what/when context, immutability, time sync, and retention to support accountability.
43
Explain Secrets management in the context of CSSLP. describe requirements for handling secrets. (Domain 2)
Unique per environment, rotation, minimal exposure, and no hard‑coding in source.
44
Explain how accessibility intersects security requirements. (Domain 2)
Controls should remain usable and accessible without weakening protections.
45
Explain SLA alignment in the context of CSSLP. describe aligning product requirements with service SLAs. (Domain 2)
Ensure stories specify operational monitoring, alerting thresholds, and support procedures to meet SLAs.
46
Describe Elicitation in the context of CSSLP. explain how security requirements are elicited alongside business requirements. (Domain 2)
Use interviews, misuse/abuse cases, threat modeling inputs, and policy review to derive explicit, testable security needs.
47
Describe Quality of requirements in the context of CSSLP. define characteristics of a good security requirement. (Domain 2)
Clear, unambiguous, testable, feasible, consistent, and traceable to objectives and risks.
48
Describe common non‑functional security requirements. (Domain 2)
Authentication strength, session lifetime, logging coverage, availability targets, and data protection objectives.
49
Describe Traceability in the context of CSSLP. explain requirements traceability and why it matters for verification. (Domain 2)
Links from source to design, code, and tests ensure nothing is missed and changes are controlled.
50
Describe how data classification influences requirements. (Domain 2)
Classification drives access, retention, encryption, and monitoring needs for each data type.
51
Describe Privacy requirements in the context of CSSLP. explain how privacy principles translate into software requirements. (Domain 2)
Minimization, consent handling, purpose limitation, and subject rights become explicit stories and acceptance criteria.
52
Describe Abuse cases in the context of CSSLP. define abuse/misuse cases and their value. (Domain 2)
They capture undesired interactions to drive preventative and detective requirements.
53
Describe the role of security acceptance criteria in user stories. (Domain 2)
They specify how security will be verified, enabling definition of done for stories with security impact.
54
Describe Prioritization in the context of CSSLP. explain how to prioritize security requirements. (Domain 2)
Use risk and business impact to sequence delivery while preserving foundational controls early.
55
Describe techniques to remove ambiguity in requirements. (Domain 2)
Use glossary, examples, decision tables, and consistent wording templates.
56
Describe Regulatory mapping concept in the context of CSSLP. explain mapping high‑level obligations into concrete software requirements. (Domain 2)
Translate obligations into specific behaviors, controls, and evidence artifacts within the product backlog.
57
Describe requirements for third‑party components and services. (Domain 2)
Define acceptance criteria for updates, vulnerability response, SLAs, and evidence needed from suppliers.
58
Describe Crypto requirements in the context of CSSLP. explain specifying cryptographic requirements without naming algorithms. (Domain 2)
State security properties (e.g., confidentiality, integrity) and key management behaviors to allow agility.
59
Describe expressing availability as a requirement. (Domain 2)
Use measurable uptime targets, RTO/RPO, and graceful‑degradation expectations.
60
Describe Error handling in the context of CSSLP. explain the requirements perspective on error/exception handling. (Domain 2)
No sensitive leakage, consistent user messages, and centralized logging for analysis.
61
Explain the typical steps of threat modeling in architecture. (Domain 3)
Define objectives, decompose system and data flows, identify threats, assess risk, and select mitigations.
62
Explain DFD/trust boundaries in the context of CSSLP. describe how trust boundaries guide control placement. (Domain 3)
Where data crosses boundaries, enforce validation, authentication, and logging; minimize exposure.
63
Explain the value of using established security design patterns. (Domain 3)
They provide proven solutions and reduce design flaws and inconsistency across teams.
64
Explain Layered architectures in the context of CSSLP. describe securing a three‑tier web architecture. (Domain 3)
Apply controls per tier: input validation and auth at web, least privilege and API security at app, encryption and access control at data.
65
Explain key architectural controls for API security. (Domain 3)
Strong authentication, authorization per operation, rate limiting, input validation, and consistent error handling.
66
Explain Zero trust mindset in the context of CSSLP. describe zero‑trust implications for application design. (Domain 3)
Never assume internal trust; continuously verify identity, context, and device posture for each request.
67
Explain secure session and state management at design time. (Domain 3)
Plan for token lifecycle, rotation, revocation, and binding to client context.
68
Explain Cryptographic boundaries in the context of CSSLP. describe how cryptographic boundaries influence architecture. (Domain 3)
Separate key storage from application logic and restrict where cleartext appears in memory or logs.
69
Explain design considerations for multi‑tenant applications. (Domain 3)
Strong tenant isolation at data and config layers, per‑tenant keys, and noisy‑neighbor protections.
70
Explain Secrets design in the context of CSSLP. describe secure design for secrets in distributed systems. (Domain 3)
Centralize secrets, restrict retrieval, audit access, and avoid passing secrets through logs or URLs.
71
Explain why canonicalization precedes validation. (Domain 3)
Normalize inputs first to avoid bypass through alternative encodings.
72
Explain Service‑to‑service auth in the context of CSSLP. describe options for service‑to‑service authentication. (Domain 3)
Mutual TLS, signed tokens, or workload identities with rotation and least privilege scopes.
73
Explain security concerns with caching strategies. (Domain 3)
Prevent sensitive data caching, set appropriate headers, and isolate per user or tenant.
74
Explain Error handling design in the context of CSSLP. describe secure error handling at architecture level. (Domain 3)
Consistent user‑safe messages with detailed logging only in secure channels; no stack traces to clients.
75
Explain designing for resilience without exposing data. (Domain 3)
Use graceful degradation, circuit breakers, and back‑pressure while preserving access control decisions.
76
Explain Event‑driven in the context of CSSLP. describe securing event‑driven architectures. (Domain 3)
Authenticate producers/consumers, validate payloads, and segregate topics/queues by sensitivity.
77
Explain partitioning strategies to reduce blast radius. (Domain 3)
Isolate high‑risk data, apply stricter controls, and minimize cross‑partition trust.
78
Explain Client‑side security in the context of CSSLP. describe design considerations for client‑side code. (Domain 3)
Avoid storing secrets, verify integrity of loaded resources, and defend against XSS and clickjacking.
79
Explain designing for safe updates of dependencies. (Domain 3)
Abstract components, pin versions, and plan for rapid replacement when issues are found.
80
Explain Telemetry by design in the context of CSSLP. describe designing telemetry for security insights. (Domain 3)
Define events, context fields, and correlation IDs to support detection and response.
81
Describe Threat modeling steps in the context of CSSLP. explain the typical steps of threat modeling in architecture. (Domain 3)
Define objectives, decompose system and data flows, identify threats, assess risk, and select mitigations.
82
Describe how trust boundaries guide control placement. (Domain 3)
Where data crosses boundaries, enforce validation, authentication, and logging; minimize exposure.
83
Describe Secure patterns in the context of CSSLP. explain the value of using established security design patterns. (Domain 3)
They provide proven solutions and reduce design flaws and inconsistency across teams.
84
Describe securing a three‑tier web architecture. (Domain 3)
Apply controls per tier: input validation and auth at web, least privilege and API security at app, encryption and access control at data.
85
Describe API security basics in the context of CSSLP. explain key architectural controls for API security. (Domain 3)
Strong authentication, authorization per operation, rate limiting, input validation, and consistent error handling.
86
Describe zero‑trust implications for application design. (Domain 3)
Never assume internal trust; continuously verify identity, context, and device posture for each request.
87
Describe State management in the context of CSSLP. explain secure session and state management at design time. (Domain 3)
Plan for token lifecycle, rotation, revocation, and binding to client context.
88
Describe how cryptographic boundaries influence architecture. (Domain 3)
Separate key storage from application logic and restrict where cleartext appears in memory or logs.
89
Describe Multi‑tenancy in the context of CSSLP. explain design considerations for multi‑tenant applications. (Domain 3)
Strong tenant isolation at data and config layers, per‑tenant keys, and noisy‑neighbor protections.
90
Describe secure design for secrets in distributed systems. (Domain 3)
Centralize secrets, restrict retrieval, audit access, and avoid passing secrets through logs or URLs.
91
Describe Input canonicalization in the context of CSSLP. explain why canonicalization precedes validation. (Domain 3)
Normalize inputs first to avoid bypass through alternative encodings.
92
Describe options for service‑to‑service authentication. (Domain 3)
Mutual TLS, signed tokens, or workload identities with rotation and least privilege scopes.
93
Describe Caching in the context of CSSLP. explain security concerns with caching strategies. (Domain 3)
Prevent sensitive data caching, set appropriate headers, and isolate per user or tenant.
94
Describe secure error handling at architecture level. (Domain 3)
Consistent user‑safe messages with detailed logging only in secure channels; no stack traces to clients.
95
Describe Resilience in the context of CSSLP. explain designing for resilience without exposing data. (Domain 3)
Use graceful degradation, circuit breakers, and back‑pressure while preserving access control decisions.
96
Explain how to implement robust input validation. (Domain 4)
Validate on the server, canonicalize first, prefer allow‑lists, and centralize validation routines.
97
Explain Output encoding in the context of CSSLP. describe output encoding and when to apply it. (Domain 4)
Transform data before rendering in specific contexts (HTML/JS/URL) to prevent injection.
98
Explain secure implementation of authentication. (Domain 4)
Use proven libraries, enforce MFA where appropriate, and protect credentials and tokens in transit and at rest.
99
Explain Authorization checks in the context of CSSLP. describe placing authorization checks in code. (Domain 4)
Enforce checks at every sensitive function and trust boundary; avoid client‑side only checks.
100
Explain secure exception handling in implementation. (Domain 4)
Catch and handle exceptions, avoid revealing internals, and ensure audited logging of security‑relevant failures.
101
Explain Logging details in the context of CSSLP. describe what to log for security without exposing secrets. (Domain 4)
Record who/what/when/where/outcome; avoid secrets and PII; protect logs from tampering.
102
Explain safe use of crypto libraries in code. (Domain 4)
Use vetted libraries, avoid custom crypto, handle keys securely, and plan for algorithm agility.
103
Explain Secrets in code in the context of CSSLP. describe practices to avoid hard‑coding secrets. (Domain 4)
Use secure vaults, environment injection at runtime, and rotation; scan repos for accidental secrets.
104
Explain controls for a secure build process. (Domain 4)
Isolate build agents, verify dependencies, and reproduce builds deterministically; sign artifacts.
105
Explain Dependency hygiene in the context of CSSLP. describe how to manage third‑party libraries safely. (Domain 4)
Pin versions, monitor advisories, and remove unused or abandoned components.
106
Explain security issues caused by concurrency. (Domain 4)
Race conditions and TOCTOU can bypass checks; use atomic operations and proper locking.
107
Explain Serialization in the context of CSSLP. describe secure serialization practices. (Domain 4)
Avoid unsafe deserializers; validate types; prefer formats with strict schemas.
108
Explain secure file upload implementation. (Domain 4)
Validate type/size, store outside web root, randomize names, and scan for malware.
109
Explain Command execution in the context of CSSLP. describe safe approaches to executing system commands. (Domain 4)
Avoid when possible; if needed, avoid shells, pass args safely, and drop privileges.
110
Explain memory‑safe implementation approaches. (Domain 4)
Use memory‑safe languages where possible and enable compiler/runtime protections.
111
Explain Mobile specifics in the context of CSSLP. describe secure storage on mobile clients. (Domain 4)
Use OS‑provided secure storage, avoid secrets in backups, and protect against rooted/jailbroken risks.
112
Explain secure REST API implementation basics. (Domain 4)
Enforce authz per method/resource, validate inputs, consistent status codes, and rate limits.
113
Explain GraphQL in the context of CSSLP. describe security considerations for GraphQL endpoints. (Domain 4)
Depth/complexity limits, query whitelists, authorization per resolver, and input validation.
114
Explain why key and secret rotation matters in code paths. (Domain 4)
Limits exposure time and supports revocation when incidents occur.
115
Explain Feature flags in the context of CSSLP. describe secure use of feature flags. (Domain 4)
Protect flags, audit changes, and avoid exposing sensitive functionality to unauthorized users.
116
Describe Input validation impl in the context of CSSLP. explain how to implement robust input validation. (Domain 4)
Validate on the server, canonicalize first, prefer allow‑lists, and centralize validation routines.
117
Describe output encoding and when to apply it. (Domain 4)
Transform data before rendering in specific contexts (HTML/JS/URL) to prevent injection.
118
Describe Authentication coding in the context of CSSLP. explain secure implementation of authentication. (Domain 4)
Use proven libraries, enforce MFA where appropriate, and protect credentials and tokens in transit and at rest.
119
Describe placing authorization checks in code. (Domain 4)
Enforce checks at every sensitive function and trust boundary; avoid client‑side only checks.
120
Describe Error handling code in the context of CSSLP. explain secure exception handling in implementation. (Domain 4)
Catch and handle exceptions, avoid revealing internals, and ensure audited logging of security‑relevant failures.
121
Describe what to log for security without exposing secrets. (Domain 4)
Record who/what/when/where/outcome; avoid secrets and PII; protect logs from tampering.
122
Describe Cryptography use in the context of CSSLP. explain safe use of crypto libraries in code. (Domain 4)
Use vetted libraries, avoid custom crypto, handle keys securely, and plan for algorithm agility.
123
Describe practices to avoid hard‑coding secrets. (Domain 4)
Use secure vaults, environment injection at runtime, and rotation; scan repos for accidental secrets.
124
Describe Secure build in the context of CSSLP. explain controls for a secure build process. (Domain 4)
Isolate build agents, verify dependencies, and reproduce builds deterministically; sign artifacts.
125
Describe how to manage third‑party libraries safely. (Domain 4)
Pin versions, monitor advisories, and remove unused or abandoned components.
126
Describe Concurrency in the context of CSSLP. explain security issues caused by concurrency. (Domain 4)
Race conditions and TOCTOU can bypass checks; use atomic operations and proper locking.
127
Describe secure serialization practices. (Domain 4)
Avoid unsafe deserializers; validate types; prefer formats with strict schemas.
128
Describe File handling in the context of CSSLP. explain secure file upload implementation. (Domain 4)
Validate type/size, store outside web root, randomize names, and scan for malware.
129
Describe safe approaches to executing system commands. (Domain 4)
Avoid when possible; if needed, avoid shells, pass args safely, and drop privileges.
130
Describe Memory safety in the context of CSSLP. explain memory‑safe implementation approaches. (Domain 4)
Use memory‑safe languages where possible and enable compiler/runtime protections.
131
Explain how to build a security test strategy for a release. (Domain 5)
Scope by risk, map to requirements, choose methods (SAST, DAST, manual), and define pass/fail criteria.
132
Explain Unit vs integration in the context of CSSLP. describe security value of unit vs integration tests. (Domain 5)
Unit tests catch logic flaws early; integration tests validate interactions and trust boundaries.
133
Explain when SAST is most effective. (Domain 5)
Early in development to catch coding weaknesses before build and deployment.
134
Explain DAST in the context of CSSLP. describe the focus of DAST. (Domain 5)
Tests running apps for exploitable issues in real interfaces and configurations.
135
Explain IAST benefits. (Domain 5)
Combines runtime insight with code knowledge for accurate findings during functional testing.
136
Explain Pen testing in the context of CSSLP. describe the purpose of penetration testing in SDLC. (Domain 5)
Validates exploitability and control effectiveness under realistic attack conditions.
137
Explain fuzz testing and when to use it. (Domain 5)
Feeds malformed inputs to reveal crashes and parsing errors; useful for parsers and APIs.
138
Explain Regression in the context of CSSLP. describe regression testing for security changes. (Domain 5)
Re‑test prior controls and functions after changes to prevent reintroducing issues.
139
Explain a 'bug bar' and how it supports release decisions. (Domain 5)
Predefined severity thresholds determine whether a build can ship.
140
Explain Coverage in the context of CSSLP. describe how to measure security test coverage. (Domain 5)
Map tests to requirements, code areas, and threat scenarios; track gaps.
141
Explain secure handling of test data. (Domain 5)
Avoid production data; mask or synthesize; protect access and clean up after tests.
142
Explain Abuse case tests in the context of CSSLP. describe creating tests from misuse/abuse cases. (Domain 5)
Turn each scenario into negative tests that assert safe handling and proper logging.
143
Explain why performance testing matters for security. (Domain 5)
Degradation can cause timeouts, failures, or unsafe fallbacks; test under load.
144
Explain Crypto validation in the context of CSSLP. describe validating cryptographic function behavior. (Domain 5)
Verify correct modes, key sizes, error handling, and failure on misuse.
145
Explain a core approach to API security testing. (Domain 5)
Systematically test authorization per endpoint, method, and data object.
146
Explain Mobile testing in the context of CSSLP. describe mobile‑specific security tests. (Domain 5)
Local data storage, clipboard exposure, URL handlers, and certificate validation.
147
Explain priorities in web app security testing. (Domain 5)
Injection, auth/session, access control, XSS, CSRF, and security headers.
148
Explain Infra as code tests in the context of CSSLP. describe testing of infrastructure‑as‑code templates. (Domain 5)
Scan for insecure defaults, open ports, excessive privileges, and missing encryption.
149
Explain managing false positives in security testing. (Domain 5)
Triage, verify with secondary methods, and tune rules to reduce noise.
150
Explain Reporting in the context of CSSLP. describe effective security test reporting. (Domain 5)
Explain risk, reproduction steps, impacted requirements, and recommended fixes.
151
Describe Test strategy in the context of CSSLP. explain how to build a security test strategy for a release. (Domain 5)
Scope by risk, map to requirements, choose methods (SAST, DAST, manual), and define pass/fail criteria.
152
Describe security value of unit vs integration tests. (Domain 5)
Unit tests catch logic flaws early; integration tests validate interactions and trust boundaries.
153
Describe SAST in the context of CSSLP. explain when SAST is most effective. (Domain 5)
Early in development to catch coding weaknesses before build and deployment.
154
Describe the focus of DAST. (Domain 5)
Tests running apps for exploitable issues in real interfaces and configurations.
155
Describe IAST in the context of CSSLP. explain IAST benefits. (Domain 5)
Combines runtime insight with code knowledge for accurate findings during functional testing.
156
Describe the purpose of penetration testing in SDLC. (Domain 5)
Validates exploitability and control effectiveness under realistic attack conditions.
157
Describe Fuzzing in the context of CSSLP. explain fuzz testing and when to use it. (Domain 5)
Feeds malformed inputs to reveal crashes and parsing errors; useful for parsers and APIs.
158
Describe regression testing for security changes. (Domain 5)
Re‑test prior controls and functions after changes to prevent reintroducing issues.
159
Describe Bug bar in the context of CSSLP. explain a 'bug bar' and how it supports release decisions. (Domain 5)
Predefined severity thresholds determine whether a build can ship.
160
Describe how to measure security test coverage. (Domain 5)
Map tests to requirements, code areas, and threat scenarios; track gaps.
161
Describe Test data in the context of CSSLP. explain secure handling of test data. (Domain 5)
Avoid production data; mask or synthesize; protect access and clean up after tests.
162
Describe creating tests from misuse/abuse cases. (Domain 5)
Turn each scenario into negative tests that assert safe handling and proper logging.
163
Describe Performance & security in the context of CSSLP. explain why performance testing matters for security. (Domain 5)
Degradation can cause timeouts, failures, or unsafe fallbacks; test under load.
164
Describe validating cryptographic function behavior. (Domain 5)
Verify correct modes, key sizes, error handling, and failure on misuse.
165
Describe API testing in the context of CSSLP. explain a core approach to API security testing. (Domain 5)
Systematically test authorization per endpoint, method, and data object.
166
Explain what it means to integrate security into the lifecycle. (Domain 6)
Security activities are embedded in each phase with defined roles, artifacts, and checkpoints.
167
Explain Change control in the context of CSSLP. describe effective change control for software releases. (Domain 6)
All changes are authorized, tested, documented, and auditable with rollback plans.
168
Explain the purpose of release management gates. (Domain 6)
Gates verify required activities and evidence are complete before moving forward.
169
Explain Baseline management in the context of CSSLP. describe baseline management for code and configurations. (Domain 6)
Approved versions are recorded and protected; deviations are detected and controlled.
170
Explain the continuous risk management loop in the SDLC. (Domain 6)
Identify, analyze, treat, and monitor risks with periodic review and escalation paths.
171
Explain Training & awareness in the context of CSSLP. describe why ongoing training matters for teams. (Domain 6)
Keeps skills current, aligns practices, and reduces repeat mistakes across sprints.
172
Explain selecting good security KPIs for lifecycle health. (Domain 6)
Choose measures tied to outcomes (defect rates, MTTR, coverage) and act on trends.
173
Explain Third‑party governance in the context of CSSLP. describe lifecycle governance for third‑party components. (Domain 6)
Define intake, review, approval, update cadence, and retirement criteria.
174
Explain why capturing evidence is part of the lifecycle. (Domain 6)
Proves activities occurred, supports audits, and accelerates incident investigations.
175
Explain Decommissioning in the context of CSSLP. describe secure software retirement steps. (Domain 6)
Plan data export/retention, revoke access, remove secrets, and validate removal from inventory.
176
Explain operational readiness review outcomes. (Domain 6)
Confirms monitoring, alerting, runbooks, and support processes are in place.
177
Explain Ownership in the context of CSSLP. describe assigning security ownership in teams. (Domain 6)
Clear RACI with accountable product owners and embedded security champions.
178
Explain managing supplier‑driven changes over the lifecycle. (Domain 6)
Track notices, assess impact, test updates, and communicate to stakeholders.
179
Explain Backlog hygiene in the context of CSSLP. describe security backlog hygiene. (Domain 6)
Review, deduplicate, size, and prioritize security work regularly with product management.
180
Explain conducting retros focused on security. (Domain 6)
Capture what worked, what failed, and actions; verify actions are completed in following sprints.
181
Explain Environment parity in the context of CSSLP. describe why environment parity matters. (Domain 6)
Keeps dev/test close to prod to reduce configuration drift and surprises at release.
182
Describe Process integration in the context of CSSLP. explain what it means to integrate security into the lifecycle. (Domain 6)
Security activities are embedded in each phase with defined roles, artifacts, and checkpoints.
183
Describe effective change control for software releases. (Domain 6)
All changes are authorized, tested, documented, and auditable with rollback plans.
184
Describe Release management in the context of CSSLP. explain the purpose of release management gates. (Domain 6)
Gates verify required activities and evidence are complete before moving forward.
185
Describe baseline management for code and configurations. (Domain 6)
Approved versions are recorded and protected; deviations are detected and controlled.
186
Describe Risk management loop in the context of CSSLP. explain the continuous risk management loop in the SDLC. (Domain 6)
Identify, analyze, treat, and monitor risks with periodic review and escalation paths.
187
Describe why ongoing training matters for teams. (Domain 6)
Keeps skills current, aligns practices, and reduces repeat mistakes across sprints.
188
Describe Metrics & KPIs in the context of CSSLP. explain selecting good security KPIs for lifecycle health. (Domain 6)
Choose measures tied to outcomes (defect rates, MTTR, coverage) and act on trends.
189
Describe lifecycle governance for third‑party components. (Domain 6)
Define intake, review, approval, update cadence, and retirement criteria.
190
Describe Document evidence in the context of CSSLP. explain why capturing evidence is part of the lifecycle. (Domain 6)
Proves activities occurred, supports audits, and accelerates incident investigations.
191
Describe secure software retirement steps. (Domain 6)
Plan data export/retention, revoke access, remove secrets, and validate removal from inventory.
192
Describe Service readiness in the context of CSSLP. explain operational readiness review outcomes. (Domain 6)
Confirms monitoring, alerting, runbooks, and support processes are in place.
193
Explain the key elements of a secure deployment plan. (Domain 7)
Defined steps, approvals, validation tests, rollback, communication, and monitoring hooks.
194
Explain Configuration drift in the context of CSSLP. describe configuration drift and how to prevent it. (Domain 7)
Unintended changes accumulate over time; use IaC, baseline checks, and automated compliance.
195
Explain a risk‑based patching approach. (Domain 7)
Prioritize by severity, exposure, exploitability, and business criticality with defined SLAs.
196
Explain Change windows in the context of CSSLP. describe why controlled change windows are used. (Domain 7)
They reduce business impact and ensure the right staff are available.
197
Explain continuous monitoring in operations. (Domain 7)
Collect and analyze telemetry to detect anomalies and policy violations quickly.
198
Explain Incident response in the context of CSSLP. describe post‑incident lessons‑learned activities. (Domain 7)
Identify root causes, improve controls, and track actions to closure.
199
Explain characteristics of a reliable backup strategy. (Domain 7)
Tested restores, separation from production credentials, and appropriate retention.
200
Explain Access review in the context of CSSLP. describe periodic access review in operations. (Domain 7)
Validate least privilege, remove dormant accounts, and re‑certify high‑risk access.
201
Explain the purpose of runbooks and playbooks. (Domain 7)
Standardize operational procedures and incident steps to reduce errors under pressure.
202
Explain Runtime protection in the context of CSSLP. describe runtime protection options. (Domain 7)
Exploit prevention, request inspection, allow/deny rules, and behavioral blocking in the app context.
203
Explain production logging best practices. (Domain 7)
Capture security‑relevant events with context; protect, centralize, and monitor logs.
204
Explain SLA adherence in the context of CSSLP. describe handling SLA breaches operationally. (Domain 7)
Escalate, communicate, execute remediation, and adjust capacity or architecture as needed.
205
Explain a simple vulnerability management loop. (Domain 7)
Discover, assess, remediate, verify, and report—continuously.
206
Explain Secrets rotation ops in the context of CSSLP. describe secrets rotation during operations. (Domain 7)
Automated rotation, minimal downtime strategies, and verification that dependents update correctly.
207
Explain scaling and resilience from an ops perspective. (Domain 7)
Use auto‑scaling, redundancy, graceful degradation, and chaos testing to validate behavior.
208
Describe Deployment planning in the context of CSSLP. explain the key elements of a secure deployment plan. (Domain 7)
Defined steps, approvals, validation tests, rollback, communication, and monitoring hooks.
209
Describe configuration drift and how to prevent it. (Domain 7)
Unintended changes accumulate over time; use IaC, baseline checks, and automated compliance.
210
Describe Patch management in the context of CSSLP. explain a risk‑based patching approach. (Domain 7)
Prioritize by severity, exposure, exploitability, and business criticality with defined SLAs.
211
Describe why controlled change windows are used. (Domain 7)
They reduce business impact and ensure the right staff are available.
212
Describe Monitoring in the context of CSSLP. explain continuous monitoring in operations. (Domain 7)
Collect and analyze telemetry to detect anomalies and policy violations quickly.
213
Describe post‑incident lessons‑learned activities. (Domain 7)
Identify root causes, improve controls, and track actions to closure.
214
Describe Backups in the context of CSSLP. explain characteristics of a reliable backup strategy. (Domain 7)
Tested restores, separation from production credentials, and appropriate retention.
215
Describe periodic access review in operations. (Domain 7)
Validate least privilege, remove dormant accounts, and re‑certify high‑risk access.
216
Describe Runbooks in the context of CSSLP. explain the purpose of runbooks and playbooks. (Domain 7)
Standardize operational procedures and incident steps to reduce errors under pressure.
217
Describe runtime protection options. (Domain 7)
Exploit prevention, request inspection, allow/deny rules, and behavioral blocking in the app context.
218
Describe Logging in prod in the context of CSSLP. explain production logging best practices. (Domain 7)
Capture security‑relevant events with context; protect, centralize, and monitor logs.
219
Describe handling SLA breaches operationally. (Domain 7)
Escalate, communicate, execute remediation, and adjust capacity or architecture as needed.
220
Describe Vulnerability management in the context of CSSLP. explain a simple vulnerability management loop. (Domain 7)
Discover, assess, remediate, verify, and report—continuously.
221
Describe secrets rotation during operations. (Domain 7)
Automated rotation, minimal downtime strategies, and verification that dependents update correctly.
222
Describe Capacity & resilience in the context of CSSLP. explain scaling and resilience from an ops perspective. (Domain 7)
Use auto‑scaling, redundancy, graceful degradation, and chaos testing to validate behavior.
223
Explain what should be verified during supplier onboarding for software components. (Domain 8)
Security expectations, update processes, evidence of development hygiene, and points of contact for issues.
224
Explain SBOM concept in the context of CSSLP. describe how an SBOM helps day‑to‑day engineering teams. (Domain 8)
Enables quick identification of affected components and accelerates updates and communication.
225
Explain how to safely consume upstream updates. (Domain 8)
Validate integrity, test in staging, monitor behavior, and roll back if anomalies occur.
226
Explain Code provenance in the context of CSSLP. describe why code provenance matters. (Domain 8)
Confidence that code comes from expected sources reduces the chance of tainted components.
227
Explain useful contract expectations for software suppliers. (Domain 8)
Defined response times, notification of issues, update commitments, and cooperation during investigations.
228
Explain Offboarding in the context of CSSLP. describe secure supplier offboarding steps. (Domain 8)
Revoke access, retrieve or delete data, and update inventories and documentation.
229
Explain safe use of package managers in builds. (Domain 8)
Pin trusted sources, verify signatures, and avoid fetching from unvetted repositories at build time.
230
Explain Toolchain trust in the context of CSSLP. describe securing the build toolchain. (Domain 8)
Hardened build environments, minimal privileges, and integrity checks for plugins and extensions.
231
Explain how often to review third‑party components. (Domain 8)
On intake and on a regular cadence; also on trigger events like disclosed issues.
232
Explain Single point of failure in the context of CSSLP. describe supply chain single points of failure and mitigation. (Domain 8)
Critical dependencies should have alternates or contingency plans to reduce disruption risk.
233
Explain securing software distribution. (Domain 8)
Use signed artifacts, checks before install, and monitored repositories or stores.
234
Explain License considerations in the context of CSSLP. describe why license terms can affect security posture. (Domain 8)
They influence update rights, security patch access, and obligations for disclosure.
235
Explain segmenting suppliers by risk. (Domain 8)
Categorize by criticality and data sensitivity to tailor oversight and controls.
236
Explain Operationalizing SBOM in the context of CSSLP. describe operational steps once an SBOM is available. (Domain 8)
Correlate with inventories, monitor advisories, and create playbooks for rapid update.
237
Explain risks from developer tools and extensions. (Domain 8)
Malicious or vulnerable tools can inject code or exfiltrate secrets; restrict and monitor their use.
238
Describe Supplier onboarding in the context of CSSLP. explain what should be verified during supplier onboarding for software components. (Domain 8)
Security expectations, update processes, evidence of development hygiene, and points of contact for issues.
239
Describe how an SBOM helps day‑to‑day engineering teams. (Domain 8)
Enables quick identification of affected components and accelerates updates and communication.
240
Describe Update intake in the context of CSSLP. explain how to safely consume upstream updates. (Domain 8)
Validate integrity, test in staging, monitor behavior, and roll back if anomalies occur.
241
Describe why code provenance matters. (Domain 8)
Confidence that code comes from expected sources reduces the chance of tainted components.
242
Describe Contract basics in the context of CSSLP. explain useful contract expectations for software suppliers. (Domain 8)
Defined response times, notification of issues, update commitments, and cooperation during investigations.
243
Describe secure supplier offboarding steps. (Domain 8)
Revoke access, retrieve or delete data, and update inventories and documentation.
244
Describe Package managers in the context of CSSLP. explain safe use of package managers in builds. (Domain 8)
Pin trusted sources, verify signatures, and avoid fetching from unvetted repositories at build time.
245
Describe securing the build toolchain. (Domain 8)
Hardened build environments, minimal privileges, and integrity checks for plugins and extensions.
246
Describe Third‑party review cadence in the context of CSSLP. explain how often to review third‑party components. (Domain 8)
On intake and on a regular cadence; also on trigger events like disclosed issues.
247
Describe supply chain single points of failure and mitigation. (Domain 8)
Critical dependencies should have alternates or contingency plans to reduce disruption risk.
248
Describe Distribution security in the context of CSSLP. explain securing software distribution. (Domain 8)
Use signed artifacts, checks before install, and monitored repositories or stores.
249
Describe why license terms can affect security posture. (Domain 8)
They influence update rights, security patch access, and obligations for disclosure.
250
Describe Supplier segmentation in the context of CSSLP. explain segmenting suppliers by risk. (Domain 8)
Categorize by criticality and data sensitivity to tailor oversight and controls.
251
What are functional requirements?
They define what the system should do — specific features, inputs, outputs, and user interactions.
252
What are non-functional requirements?
They define how the system performs — qualities like performance, security, scalability, and usability.
253
Give an example of a functional requirement.
System must allow users to log in using a username and password.
254
Give an example of a non-functional requirement.
System must support 10,000 concurrent users with <2s response time.
255
What document often captures functional requirements?
Functional specification or use case document.
256
What document often captures non-functional requirements?
System requirements specification (SRS).
257
What’s the main focus difference between functional and non-functional requirements?
Functional = what it does; Non-functional = how it performs.
258
What is authentication?
Verifying the identity of users or systems before granting access.
259
What is authorization?
Determining what authenticated users or systems can do.
260
What is the purpose of data encryption?
To protect sensitive data by converting it into a secure format.
261
What is input validation?
Ensuring all inputs are validated and sanitized to prevent attacks.
262
Why is error handling important?
To avoid exposing internal details or sensitive info through error messages.
263
What is vulnerability management?
Identifying, assessing, and mitigating known software vulnerabilities.
264
What is secure configuration?
Setting systems and software securely by default, reducing the attack surface.
265
What is incident response planning?
Preparing for and managing security incidents effectively.
266
What is confidentiality in security?
Ensuring data is accessible only to authorized users.
267
What algorithm is used for encryption at rest?
AES-256.
268
What protocol secures data in transit?
Transport Layer Security (TLS).
269
What is RBAC?
Role-Based Access Control — access based on user roles.
270
What is the least privilege principle?
Grant only the minimum access needed for tasks.
271
What is data masking?
Hiding sensitive data in displays or non-production environments.
272
What is data anonymization?
Removing personal identifiers to prevent identification.
273
Why is MFA important?
It adds layers of authentication to prevent unauthorized access.
274
What is secure data disposal?
Permanently removing sensitive data to prevent recovery.
275
What is data integrity?
Ensuring data remains accurate and unaltered during storage or transmission.
276
What is hashing used for?
To verify data integrity using cryptographic hash values.
277
What is a checksum?
A value used to detect accidental changes to data.
278
What is a digital signature?
A method to ensure data integrity and authenticity.
279
What is source code integrity?
Ensuring source code is not tampered with throughout development.
280
What is file integrity monitoring?
Tool-based monitoring for unauthorized changes to critical files.
281
What are ACID properties?
Atomicity, Consistency, Isolation, Durability — ensures reliable transactions.
282
Why maintain audit trails?
To track all activities affecting data integrity.
283
What is availability?
Ensuring systems are operational and accessible when needed.
284
What is redundancy?
Using backup components to eliminate single points of failure.
285
What is fault tolerance?
Ability to continue functioning even when some components fail.
286
What is a high availability cluster?
Multiple servers providing continuous service with automatic failover.
287
What is load balancing?
Distributing workloads across servers to maintain performance.
288
What is a disaster recovery plan?
Plan to restore operations after major failure or disaster.
289
What is real-time monitoring?
Continuous tracking of system performance to detect issues early.
290
What is scalability?
Ability of a system to handle increased load efficiently.
291
What is an SLA?
Service Level Agreement defining uptime and availability targets.
292
What is an SRTM?
A matrix linking security requirements to design, implementation, and testing.
293
What is the main benefit of SRTM?
Ensures all security requirements are addressed and verified.
294
What is a verification method in SRTM?
Defines how each security requirement will be tested or validated.
295
Why use an SRTM?
To ensure traceability, accountability, and compliance of security requirements.
296
What does SRTM track?
Requirement ID, source, implementation, verification, and status.
297
What are functional requirements?
They define what the system should do — specific features, inputs, outputs, and user interactions.
298
What are non-functional requirements?
They define how the system performs — qualities like performance, security, scalability, and usability.
299
Give an example of a functional requirement.
System must allow users to log in using a username and password.
300
Give an example of a non-functional requirement.
System must support 10,000 concurrent users with <2s response time.
301
What document often captures functional requirements?
Functional specification or use case document.
302
What document often captures non-functional requirements?
System requirements specification (SRS).
303
What’s the main focus difference between functional and non-functional requirements?
Functional = what it does; Non-functional = how it performs.
304
What is authentication?
Verifying the identity of users or systems before granting access.
305
What is authorization?
Determining what authenticated users or systems can do.
306
What is the purpose of data encryption?
To protect sensitive data by converting it into a secure format.
307
What is input validation?
Ensuring all inputs are validated and sanitized to prevent attacks.
308
Why is error handling important?
To avoid exposing internal details or sensitive info through error messages.
309
What is vulnerability management?
Identifying, assessing, and mitigating known software vulnerabilities.
310
What is secure configuration?
Setting systems and software securely by default, reducing the attack surface.
311
What is incident response planning?
Preparing for and managing security incidents effectively.
312
What is confidentiality in security?
Ensuring data is accessible only to authorized users.
313
What algorithm is used for encryption at rest?
AES-256.
314
What protocol secures data in transit?
Transport Layer Security (TLS).
315
What is RBAC?
Role-Based Access Control — access based on user roles.
316
What is the least privilege principle?
Grant only the minimum access needed for tasks.
317
What is data masking?
Hiding sensitive data in displays or non-production environments.
318
What is data anonymization?
Removing personal identifiers to prevent identification.
319
Why is MFA important?
It adds layers of authentication to prevent unauthorized access.
320
What is secure data disposal?
Permanently removing sensitive data to prevent recovery.
321
What is data integrity?
Ensuring data remains accurate and unaltered during storage or transmission.
322
What is hashing used for?
To verify data integrity using cryptographic hash values.
323
What is a checksum?
A value used to detect accidental changes to data.
324
What is a digital signature?
A method to ensure data integrity and authenticity.
325
What is source code integrity?
Ensuring source code is not tampered with throughout development.
326
What is file integrity monitoring?
Tool-based monitoring for unauthorized changes to critical files.
327
What are ACID properties?
Atomicity, Consistency, Isolation, Durability — ensures reliable transactions.
328
Why maintain audit trails?
To track all activities affecting data integrity.
329
What is availability?
Ensuring systems are operational and accessible when needed.
330
What is redundancy?
Using backup components to eliminate single points of failure.
331
What is fault tolerance?
Ability to continue functioning even when some components fail.
332
What is a high availability cluster?
Multiple servers providing continuous service with automatic failover.
333
What is load balancing?
Distributing workloads across servers to maintain performance.
334
What is a disaster recovery plan?
Plan to restore operations after major failure or disaster.
335
What is real-time monitoring?
Continuous tracking of system performance to detect issues early.
336
What is scalability?
Ability of a system to handle increased load efficiently.
337
What is an SLA?
Service Level Agreement defining uptime and availability targets.
338
What is an SRTM?
A matrix linking security requirements to design, implementation, and testing.
339
What is the main benefit of SRTM?
Ensures all security requirements are addressed and verified.
340
What is a verification method in SRTM?
Defines how each security requirement will be tested or validated.
341
Why use an SRTM?
To ensure traceability, accountability, and compliance of security requirements.
342
What does SRTM track?
Requirement ID, source, implementation, verification, and status.
CSSLP DC
flashcards
Decks in class (13)
# Cards
-
CSSLP General327
-
CSSLP Domain 1 – Secure Software Concepts50
-
CSSLP Domain 2 – Secure Software Requirements97
-
CSSLP Domain 3 – Secure Software Architecture and Design71
-
CSSLP Domain 4 – Secure Software Implementation98
-
CSSLP Domain 5 – Secure Software Testin26
-
CSSLP Domain 6 – Secure Software Lifecycle Management101
-
CSSLP Domain 7 – Secure Software Deployment, Operations, and Maintenance96
-
CSSLP Domain 8 – Secure Software Supply Chain96
-
NIST 800-218100
-
CSSLP Study Notes342
-
NIST-800-64r2 (Replaced By 800-218)36
-
SSDLC Gated Process90
