- CIA triad
- Confidentiality, Integrity, and Availability — the three core goals of information security that every software security control supports.
- Confidentiality
- Preventing unauthorized disclosure of data, typically enforced with encryption and access control.
- Integrity
- Ensuring data and code are accurate and unaltered except by authorized parties; enforced with hashing, digital signatures, and input validation.
- Availability
- Ensuring authorized users have timely, reliable access to software and data; supported by redundancy, resilience, and load handling.
- Authentication
- Proving a claimed identity using a credential (something you know, have, or are) before access is granted.
- Authorization
- Determining what an authenticated identity is allowed to do — which resources and actions are permitted.
- Accountability
- Tying actions back to a specific identity through logging, auditing, and monitoring.
- Non-repudiation
- Assurance that a party cannot deny performing an action; achieved with digital signatures and reliable logging.
- Least privilege
- Granting each user, process, and component only the minimum access needed to do its job — and nothing more.
- Defense in depth
- Layering multiple, overlapping controls so that if one fails, others still protect the asset.
- Separation of duties
- Splitting a sensitive task so no single person (or component) can complete it alone, reducing fraud and error.
- Fail-secure (fail-safe)
- Designing a system so that when it fails, it defaults to a secure/denied state rather than an open/permissive one.
- Complete mediation
- Checking authorization on every access to an object, every time — never relying on a cached or prior decision.
- Open design
- Security should not depend on the secrecy of the design or implementation — the opposite of security through obscurity.
- Economy of mechanism
- Keep the design as simple and small as possible — simpler systems have a smaller attack surface and fewer flaws.
- Psychological acceptability
- Security controls must be easy to use, or users will bypass them; usability is a security design principle.
- Least common mechanism
- Minimize shared mechanisms (e.g., shared resources) between users to reduce unintended access paths.
- Attack surface
- The total set of points (inputs, interfaces, code paths) where an attacker could try to enter or extract data; secure design reduces it.
- GRC
- Governance, Risk, and Compliance — the framework for aligning software security with policy, risk tolerance, and regulations.
- Defense in breadth vs. depth
- Depth = layered controls along one path; breadth = covering all the different attack vectors. Secure software needs both.
- Threat vs. vulnerability vs. risk
- A threat is a potential cause of harm; a vulnerability is a weakness it can exploit; risk is the likelihood and impact of that exploitation.
- Single point of failure
- A component whose failure takes down the whole system; secure/resilient design eliminates it through redundancy.
- Security control types
- Preventive, detective, corrective, deterrent, recovery, and compensating — categorized by function across administrative, technical, and physical classes.
- Trust boundary
- A point where data or control passes between components of differing trust levels; a prime place to validate and authorize.
- Secure by design / secure by default
- Building security in from the start and shipping with the most secure settings enabled out of the box.
- SDLC
- Software Development Lifecycle — the phases software moves through: requirements, design, implementation, testing, deployment, operations, and decommissioning.
- Secure SDLC
- Building security into every phase of the SDLC instead of testing for it at the end — the central idea of the CSSLP.
- Shift left
- Moving security activities (threat modeling, testing) earlier in the lifecycle, where flaws are cheaper to fix.
- Waterfall model
- A sequential development model with distinct phases; rigid but predictable — good for stable requirements.
- Agile model
- Iterative development in short sprints with frequent delivery; security must be embedded in each iteration.
- DevSecOps
- Integrating automated security into CI/CD so security testing and gates run continuously alongside development and operations.
- Spiral model
- An iterative model that performs explicit risk analysis at the start of each cycle.
- BSIMM
- Building Security In Maturity Model — a descriptive model that measures a software security program against observed real-world practices.
- OWASP SAMM
- Software Assurance Maturity Model — a prescriptive framework for assessing and improving a secure-software program.
- Security gate / milestone
- A checkpoint in the lifecycle where security criteria must be met before work proceeds to the next phase.
- Security metrics
- Quantitative measures (e.g., defect density, time-to-remediate, coverage) used to track and improve software security.
- Configuration management
- Controlling and tracking changes to code, builds, and environments so the system stays in a known, secure state.
- Version control
- Tracking and managing changes to source code over time; underpins traceability, rollback, and code integrity.
- Decommissioning / end-of-life
- Securely retiring software: removing access, sanitizing data, archiving as required, and disposing of credentials and keys.
- Security culture
- Organization-wide awareness, training, and shared responsibility that makes secure development the default behavior.
- NIST SSDF (SP 800-218)
- The Secure Software Development Framework — a set of high-level secure-development practices grouped into Prepare, Protect, Produce, and Respond.
- Quality assurance vs. security assurance
- QA checks the software does what it should; security assurance checks it does NOT do what it shouldn't (abuse cases, misuse).
- Continuous improvement
- Feeding lessons learned, metrics, and incident findings back into the process so each release is more secure than the last.
- Secure software roadmap / strategy
- A planned set of security objectives, controls, and maturity goals aligned to business risk over time.
- Risk management in the SDLC
- Identifying, assessing, treating, and monitoring software risk continuously across every phase, not just once.
- Functional security requirement
- A requirement stating a security feature the system must DO (e.g., 'lock the account after 5 failed logins').
- Non-functional security requirement
- A quality the system must HAVE (e.g., confidentiality, performance, resilience) rather than a discrete feature.
- Misuse case
- A scenario describing how an actor could intentionally abuse the system; the inverse of a use case, used to derive security requirements.
- Abuse case
- A deliberate, hostile interaction with the system used to surface threats and the controls needed to stop them.
- Requirements Traceability Matrix (RTM)
- A grid mapping each (security) requirement to its design, code, and test, proving every requirement is implemented and verified.
- Data classification
- Labeling data by sensitivity (e.g., public, internal, confidential, restricted) so the right protection is applied throughout its lifecycle.
- Data lifecycle
- The stages data moves through: create, store, use, share, archive, and destroy — each needing appropriate controls.
- PII
- Personally Identifiable Information — data that can identify an individual; subject to privacy requirements and special handling.
- Privacy by design
- Embedding privacy protections (data minimization, consent, retention limits) into requirements and design from the outset.
- Data minimization
- Collecting and retaining only the data actually needed for the purpose — a core privacy requirement.
- Cross-border data requirements
- Legal constraints on transferring personal data between jurisdictions (e.g., GDPR), which become software requirements.
- Compliance requirements
- Obligations from laws, regulations, and standards (GDPR, HIPAA, PCI DSS) that translate into specific security requirements.
- PCI DSS
- Payment Card Industry Data Security Standard — security requirements for systems that store, process, or transmit cardholder data.
- Subject / object / activity matrix
- A requirements technique listing who (subjects) can do what (activities) to which data (objects) — drives access requirements.
- Security requirement sources
- Derived from policy, regulations, risk assessment, abuse/misuse cases, data classification, and stakeholder needs.
- Third-party / supplier security requirements
- Security specifications imposed on vendors and components the software depends on, set during requirements.
- Data retention requirement
- How long data must be kept and when it must be destroyed, driven by legal, regulatory, and privacy obligations.
- Functional vs. assurance requirements
- Functional requirements say what security to build; assurance requirements say how much confidence (evidence/testing) is required.
- Use case vs. misuse case
- A use case shows legitimate behavior; a misuse case shows hostile behavior — together they define needed security controls.
- Sensitive data discovery
- Identifying where regulated/sensitive data lives in the system so requirements can mandate its protection.
- Threat modeling
- Systematically identifying, enumerating, and prioritizing threats to a design so controls can be chosen before code is written.
- STRIDE
- A threat taxonomy: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege.
- PASTA
- Process for Attack Simulation and Threat Analysis — a risk-centric, seven-stage threat modeling methodology.
- DREAD
- A (legacy) risk-rating model: Damage, Reproducibility, Exploitability, Affected users, Discoverability.
- Attack tree
- A diagram that breaks an attacker goal (root) into the steps and sub-steps needed to achieve it; used to analyze threats.
- Data flow diagram (DFD)
- A model of how data moves between processes, stores, and external entities across trust boundaries — the basis for STRIDE threat modeling.
- Security design pattern
- A reusable, proven solution to a recurring security problem (e.g., secure proxy, single access point, defense in depth).
- Symmetric encryption
- Encryption using one shared secret key for both encryption and decryption (e.g., AES) — fast, but key distribution is hard.
- Asymmetric encryption
- Encryption using a public/private key pair (e.g., RSA, ECC) — slower, but it solves key exchange and enables digital signatures.
- Hashing
- A one-way function producing a fixed-length digest (e.g., SHA-256) used to verify integrity; it is not reversible.
- Digital signature
- A hash of a message encrypted with the sender's private key, providing integrity, authenticity, and non-repudiation.
- PKI
- Public Key Infrastructure — the certificate authorities, certificates, and policies that manage public keys and trust.
- Key management
- The full lifecycle of cryptographic keys: generation, distribution, storage, rotation, and destruction — often the weakest link.
- Architectural risk assessment
- Evaluating a design for security weaknesses and prioritizing them by risk before implementation begins.
- Secure interface / API design
- Designing interfaces with authentication, authorization, input validation, rate limiting, and minimal exposed surface.
- Cloud security architecture
- Designing for the shared-responsibility model, multitenancy isolation, identity federation, and data protection in cloud environments.
- Mobile / IoT / embedded security
- Architectures must address constrained resources, untrusted networks, physical access, and secure update of distributed devices.
- Microservices security
- Securing distributed services with mutual TLS, per-service identity, API gateways, and zero-trust between components.
- Zero trust
- An architecture that never implicitly trusts based on network location — every request is authenticated and authorized.
- Sandboxing
- Isolating untrusted code or processes in a confined environment so it cannot affect the rest of the system.
- Tokenization vs. encryption
- Tokenization replaces sensitive data with a non-sensitive token (no math link); encryption transforms data reversibly with a key.
- Security control prioritization
- Choosing which controls to apply first based on the risk they reduce versus their cost — output of architectural risk analysis.
- Trust zone segmentation
- Partitioning the architecture into zones of differing trust (e.g., DMZ, internal) with controls at each boundary.
- Inference / aggregation
- Inference = deducing protected data from accessible data; aggregation = combining harmless data into sensitive data. Design must mitigate both.
- Cryptographic agility
- Designing so algorithms and key lengths can be swapped out as standards change, without re-architecting the system.
- Secure coding
- Writing code that resists abuse: validating input, encoding output, handling errors safely, and using vetted security APIs.
- Input validation
- Checking all input against an allowlist of expected format/type/range before use — the primary defense against injection.
- Output encoding
- Encoding data for the context it is rendered in (HTML, JS, SQL, URL) so it is treated as data, not executable code.
- SQL injection
- Inserting malicious SQL through unvalidated input to read or alter a database; prevented by parameterized queries and input validation.
- Parameterized query
- A query where user data is bound as parameters, never concatenated into the SQL string — the definitive fix for SQL injection.
- Cross-site scripting (XSS)
- Injecting malicious script into web output so it runs in another user's browser; prevented by output encoding and a Content Security Policy.
- Cross-site request forgery (CSRF)
- Tricking a logged-in user's browser into sending an unwanted request; prevented with anti-CSRF tokens and SameSite cookies.
- Buffer overflow
- Writing past the bounds of a memory buffer to corrupt data or execute code; prevented by bounds checking and safe languages/functions.
- OWASP Top 10
- A community list of the most critical web application security risks (e.g., broken access control, injection, cryptographic failures).
- CWE / SANS Top 25
- The MITRE Common Weakness Enumeration and the list of the 25 most dangerous software weaknesses — a coding-error reference.
- Error & exception handling
- Failing securely: catch errors, log them safely, and never leak stack traces or sensitive details to the user.
- Secure memory management
- Avoiding overflows, use-after-free, and leaks; preferring memory-safe languages or safe library functions.
- SAST
- Static Application Security Testing — analyzing source code (without running it) to find vulnerabilities early. Also called static analysis.
- Manual code review / peer review
- Humans reading code to find logic and security flaws that automated tools miss; especially valuable for auth and crypto code.
- Anti-tampering
- Techniques (code signing, obfuscation, integrity checks) that detect or prevent unauthorized modification of software.
- Code signing
- Digitally signing a build so users can verify it came from the real publisher and has not been altered.
- Secure build process
- A reproducible, protected pipeline that compiles trusted source into trusted artifacts, free of injected or unauthorized code.
- Malicious code / logic bomb
- Code intentionally inserted to cause harm (backdoor, logic bomb, trojan); detected through review and integrity verification.
- Type safety
- Enforcing that operations only act on compatible data types, preventing a class of memory and logic vulnerabilities.
- Canonicalization
- Reducing input to its simplest, standard form before validation, so attackers cannot bypass checks with alternate encodings.
- Allowlist vs. denylist
- Allowlisting permits only known-good input (preferred, secure by default); denylisting blocks known-bad and misses novel attacks.
- Race condition / TOCTOU
- A flaw where the state changes between a check and its use (Time-Of-Check to Time-Of-Use); fixed with atomic operations/locking.
- Hardcoded secrets
- Embedding credentials or keys in source code — a serious flaw; secrets belong in a vault or secure configuration, never in code.
- Secure defaults in code
- Initializing variables, permissions, and configurations to their safest values so omissions fail closed, not open.
- Integer overflow
- An arithmetic result exceeding the variable's range, wrapping to a wrong (often small) value and enabling overflow attacks.
- Security test strategy
- A plan defining what security to test, how, when, and with which tools across the lifecycle — driven by requirements and risk.
- DAST
- Dynamic Application Security Testing — testing a running application from the outside (black-box) to find runtime vulnerabilities.
- SAST vs. DAST
- SAST inspects source code at rest (early, white-box); DAST exercises a running app (later, black-box). Use both for coverage.
- IAST
- Interactive Application Security Testing — instruments a running app to combine inside knowledge (like SAST) with live execution (like DAST).
- Fuzzing
- Feeding large volumes of malformed or random input to a program to discover crashes and security flaws.
- Penetration testing
- An authorized, simulated attack that actively exploits weaknesses to demonstrate real impact, performed under rules of engagement.
- Vulnerability scanning
- Automated checking for known weaknesses without exploiting them; broad and frequent, unlike a pen test.
- Functional vs. non-functional testing
- Functional security tests verify a control works (e.g., lockout); non-functional tests check qualities like resilience and performance under load.
- Negative / abuse-case testing
- Testing what the software should reject or prevent (invalid input, misuse) rather than only the happy path.
- Test case from misuse case
- Deriving concrete security test cases directly from the misuse/abuse cases identified in requirements.
- Verification vs. validation
- Verification asks 'did we build it right?' (meets spec); validation asks 'did we build the right thing?' (meets the real need).
- Regression testing
- Re-running tests after changes to confirm previously fixed vulnerabilities and working controls were not broken.
- Test data management
- Using anonymized, masked, or synthetic data in test environments so real sensitive data is never exposed.
- Data anonymization vs. masking
- Anonymization irreversibly removes identifying detail; masking obscures data while keeping format — both protect test data.
- CVSS
- Common Vulnerability Scoring System — a 0–10 standard for rating the severity of a vulnerability, used to prioritize fixes.
- False positive vs. false negative
- A false positive flags a non-issue (wastes effort); a false negative misses a real flaw (dangerous). Tuning balances them.
- Code coverage
- A metric of how much code the tests exercise; high coverage increases (but does not guarantee) confidence in security testing.
- Security test environment
- An isolated environment mirroring production where security testing runs without risking real systems or data.
- Defect tracking / remediation
- Logging, prioritizing (e.g., by CVSS), assigning, and verifying the fix of each security defect found in testing.
- Black-box / white-box / gray-box
- Test perspectives by knowledge: black-box (none), white-box (full source/design), gray-box (partial).
- Secure deployment
- Releasing software with hardened configuration, least-privilege accounts, and verified integrity into a controlled environment.
- Hardening
- Reducing a system's attack surface by removing unnecessary services, accounts, and software and applying secure settings.
- Secure baseline / configuration
- A documented, approved secure starting configuration that all deployments must match and drift away from is detected.
- CI/CD pipeline security
- Protecting the automated build/test/deploy pipeline with access control, signed artifacts, and integrated security gates.
- Continuous monitoring
- Ongoing collection and analysis of logs, events, and metrics to detect security issues in operations.
- Incident response
- The structured process to detect, contain, eradicate, recover from, and learn from a security incident.
- Patch management
- Tracking, testing, and applying security updates to software and dependencies promptly and in a controlled way.
- Vulnerability management
- The ongoing cycle of identifying, prioritizing, remediating, and verifying vulnerabilities in deployed software.
- RASP
- Runtime Application Self-Protection — security built into the running application that detects and blocks attacks in real time.
- WAF
- Web Application Firewall — a control that inspects and filters HTTP traffic to block common web attacks before they reach the app.
- Operational risk analysis
- Assessing the risks introduced once software is live (configuration, dependencies, environment) and the controls to manage them.
- Change management
- A controlled process for evaluating, approving, documenting, and rolling back changes to deployed software.
- Business continuity plan (BCP)
- A plan to keep critical business functions running during and after a disruption.
- Disaster recovery (DR)
- The processes to restore IT systems and software operations after a disruptive event.
- RTO
- Recovery Time Objective — the target time to restore a system after a disruption; must be shorter than the maximum tolerable downtime.
- RPO
- Recovery Point Objective — the maximum acceptable data loss measured backward in time; it drives backup frequency.
- Secure decommissioning
- Retiring software safely: revoking access and keys, sanitizing data, and removing the system from monitoring and inventory.
- Security approval to operate
- A formal sign-off (authorization) that residual risk is acceptable before software goes or stays in production.
- Blue-green / canary deployment
- Release strategies that limit blast radius by running a new version alongside the old and shifting traffic gradually.
- Infrastructure as Code (IaC) security
- Scanning and controlling declarative infrastructure definitions so misconfigurations are caught before deployment.
- Logging and audit trail
- Recording security-relevant events tamper-resistantly so incidents can be detected, investigated, and attributed.
- Software supply chain
- Everything that goes into building and delivering software: source, dependencies, build tools, and distribution.
- Supply chain risk management (SCRM)
- Identifying and mitigating security risks from third-party and open-source components and suppliers across the lifecycle.
- SBOM
- Software Bill of Materials — a complete inventory of components and dependencies in a piece of software, used to track and respond to risk.
- Software composition analysis (SCA)
- Tooling that inventories open-source/third-party components and flags known vulnerabilities and license issues.
- Pedigree and provenance
- Pedigree is a component's history of changes; provenance is where it originated — both verify a component's trustworthiness.
- Dependency / transitive risk
- Risk inherited from libraries your code uses — and from the libraries THOSE use (transitive dependencies).
- Third-party / COTS risk
- Security risk from commercial off-the-shelf and externally acquired software that you cannot fully inspect or control.
- Supplier security requirements
- Security obligations placed on vendors via contracts, SLAs, and audits to ensure their components meet your standards.
- Code repository security
- Protecting source repositories with access control, branch protection, signed commits, and secret scanning.
- Dependency confusion
- An attack where a malicious public package with a private package's name is pulled into a build; mitigated by namespace/scope controls.
- Typosquatting
- Publishing a malicious package with a name close to a popular one, hoping developers install it by mistake.
- Build integrity / SLSA
- Ensuring artifacts are built from trusted source by a trusted, tamper-resistant pipeline (e.g., the SLSA framework).
- Vendor / supplier audit
- Assessing a supplier's security practices (questionnaires, certifications, SOC 2) before and during reliance on them.
- Open-source license risk
- Legal risk from using components under restrictive licenses; tracked alongside vulnerabilities in SCA and the SBOM.
- Component vulnerability response
- Monitoring advisories, mapping them to your SBOM, and patching or replacing affected components quickly.
- Code signing in the supply chain
- Signing and verifying components and releases so each link in the chain can confirm integrity and origin.
- NIST SP 800-161
- NIST guidance on cybersecurity supply chain risk management practices for systems and organizations.
- Security through obscurity
- Relying on secrecy of design as the main protection — discouraged; it violates the open-design principle and fails once the secret leaks.
- Defense in depth vs. single control
- No single control should be trusted alone; layering ensures the failure of one control does not expose the asset.
- Need to know
- Limiting access to the specific information required for a task, even among authorized users; pairs with least privilege.
- Subject vs. object
- A subject is an active entity (user, process) that acts; an object is a passive resource (file, record) acted upon.
- Qualitative vs. quantitative risk
- Qualitative risk ranks risks subjectively (high/medium/low); quantitative risk assigns dollar values (e.g., ALE = SLE × ARO).
- Risk treatment options
- Mitigate (reduce with controls), transfer (e.g., insurance), avoid (stop the activity), or accept (formally tolerate the residual risk).
- Residual risk
- The risk that remains after controls are applied; management must formally accept it.
- Confidentiality vs. privacy
- Confidentiality protects data from disclosure; privacy concerns an individual's right to control how their personal data is used.
- Software assurance
- Justified confidence that software is free from vulnerabilities and functions as intended — the goal of the secure SDLC.
- Threat modeling timing
- Threat modeling belongs early (requirements/design), so threats are addressed before code makes them expensive to fix.
- Security champion
- A developer embedded in a team who advocates for security practices and bridges to the security team.
- Definition of done (security)
- Including security criteria (tests passed, no high findings) in a story's acceptance, so security is part of 'done.'
- Cost of fixing flaws over time
- Defects cost far more to fix the later they are found — cheapest in design, most expensive in production. The case for shifting left.
- Maturity model purpose
- BSIMM/SAMM let an organization measure where its software-security program stands and plan concrete improvements.
- Secure SDLC gates
- Predefined security checkpoints (design review, code review, pen test) that must pass before moving to the next phase.
- Security requirement vs. control
- A requirement states the security need; a control is the specific mechanism implemented to satisfy it.
- Regulatory vs. contractual requirements
- Regulatory requirements come from law (GDPR, HIPAA); contractual ones come from agreements (PCI DSS, customer contracts).
- GDPR
- The EU General Data Protection Regulation — governs processing of personal data, consent, breach notice, and cross-border transfer.
- HIPAA
- U.S. law setting privacy and security requirements for protected health information (PHI).
- Data ownership roles
- Owner (accountable, sets classification), custodian (implements controls), and processor (handles data on the controller's behalf).
- Security policy decomposition
- Translating high-level policy into specific, testable security requirements the software must meet.
- Anti-requirements
- Explicit statements of what the system must NOT do or allow, derived from abuse/misuse cases.
- Attack surface analysis
- Enumerating every entry point, interface, and data path to understand and reduce where attacks can occur.
- Secure design review
- A structured evaluation of the architecture against security principles and threat models before implementation.
- Bell-LaPadula model
- A confidentiality model: 'no read up, no write down' — prevents information flow to lower security levels.
- Biba model
- An integrity model: 'no read down, no write up' — prevents contamination of high-integrity data by lower-integrity sources.
- Reference monitor
- The abstract concept that mediates all access between subjects and objects; implemented by the security kernel.
- Salting (passwords)
- Adding a unique random value to each password before hashing, so identical passwords produce different hashes and rainbow tables fail.
- Key length and algorithm choice
- Choosing strong, current algorithms (AES, SHA-256, RSA-2048+) and adequate key lengths is a design-time decision.
- Secure session management
- Designing session IDs to be random, transmitted over TLS, expired/idle-timed, and invalidated on logout to prevent hijacking.
- Federated identity
- Letting users authenticate once with a trusted identity provider (e.g., SAML, OIDC) and access multiple services.
- Defense-in-depth in architecture
- Placing controls at every tier (client, network, app, data) so a breach of one layer is contained by the next.
- Threat model deliverable
- The output: a list of threats (by STRIDE category), their risk, and the mitigations/controls assigned to each.
- Broken access control
- Failing to enforce what users are allowed to do; the #1 web risk — enforce authorization on the server for every request.
- Cryptographic failures
- Weak or missing encryption, bad key handling, or outdated algorithms exposing sensitive data; an OWASP Top 10 category.
- Insecure deserialization
- Trusting serialized data from users so it can execute code or tamper with objects; validate and avoid native deserialization of untrusted data.
- Command injection
- Passing unvalidated input into an OS command; prevented by avoiding shell calls and using safe APIs with strict input validation.
- Path traversal
- Using '../' sequences in input to access files outside the intended directory; prevented by canonicalization and allowlists.
- Server-side request forgery (SSRF)
- Tricking a server into making requests to unintended internal targets; mitigated by allowlisting destinations and blocking internal ranges.
- Secure logging
- Logging security events without recording secrets/PII, and protecting logs from tampering.
- Use-after-free
- Accessing memory after it has been freed, leading to crashes or code execution; avoided by memory-safe practices and languages.
- Secure random number generation
- Using a cryptographically secure RNG (not a predictable PRNG) for tokens, keys, and session IDs.
- Content Security Policy (CSP)
- A browser-enforced allowlist of content sources that helps mitigate XSS by restricting where scripts can load from.
- Secrets management
- Storing credentials and keys in a vault/secret manager with rotation and access control — never hardcoded or in config files.
- Security regression suite
- An automated set of security tests run on each build to ensure fixed vulnerabilities do not reappear.
- Pen test rules of engagement
- The agreed scope, timing, methods, and limits for a penetration test; testing without authorization is a crime.
- Test coverage vs. risk-based testing
- Risk-based testing focuses effort on the highest-risk areas rather than treating all code equally.
- Triaging findings
- Reviewing tool output to remove false positives and prioritize true vulnerabilities by severity (e.g., CVSS) before remediation.
- Stress / load testing (security)
- Testing how the system behaves under extreme load to confirm availability controls and graceful failure.
- Acceptance / security sign-off
- Confirming all security test criteria are met before a release is approved to ship.
- Synthetic test data
- Artificially generated data that mimics production format without using real sensitive records.
- Secure configuration drift
- When a live system diverges from its approved secure baseline; continuous monitoring detects and corrects it.
- Least privilege at deployment
- Running services and accounts with the minimum permissions needed, so a compromise has limited reach.
- Immutable infrastructure
- Replacing servers/containers with fresh, known-good images on each deploy instead of patching in place, reducing drift and tampering.
- Container / image security
- Scanning images for vulnerabilities, using minimal trusted base images, and signing them before deployment.
- Incident response phases
- Preparation; detection & analysis; containment, eradication & recovery; and post-incident (lessons learned).
- MTTD / MTTR
- Mean Time To Detect and Mean Time To Respond/Recover — key operational security metrics to minimize.
- Patch testing before deploy
- Validating patches in a staging environment so a security fix does not break functionality in production.
- Backup types
- Full (everything), incremental (changes since any backup — slow restore), differential (changes since last full — faster restore).
- Chain of custody
- Documentation of who handled evidence and when, preserving its integrity for an investigation or legal use.
- Open-source vs. proprietary risk
- Open source is inspectable but unsupported by a vendor; proprietary is supported but opaque — both need supply-chain controls.
- SBOM formats
- Standardized machine-readable formats (e.g., SPDX, CycloneDX) used to express a software bill of materials.
- Vendor risk tiering
- Classifying suppliers by the risk they pose so the highest-risk vendors get the most scrutiny and controls.
- Provenance verification
- Confirming a component truly originated from its claimed, trusted source before it enters the build.
- Continuous dependency scanning
- Automatically re-checking dependencies against new advisories so newly disclosed flaws are caught after release.
- Software escrow
- Depositing source code with a trusted third party so a customer can recover it if the supplier fails — a supply-chain safeguard.
- Trusted package registry
- Pulling components only from vetted, controlled internal/mirror registries to reduce dependency-confusion and typosquatting risk.
- STRIDE: Spoofing
- Pretending to be someone/something else; mitigated by strong authentication.
- STRIDE: Tampering
- Unauthorized modification of data or code; mitigated by integrity controls (hashing, signatures, access control).
- STRIDE: Repudiation
- Denying an action was performed; mitigated by non-repudiation controls (logging, digital signatures).
- STRIDE: Information disclosure
- Exposing data to unauthorized parties; mitigated by encryption and access control (confidentiality).
- STRIDE: Denial of service
- Making a system unavailable; mitigated by rate limiting, resilience, and redundancy (availability).
- STRIDE: Elevation of privilege
- Gaining higher rights than authorized; mitigated by least privilege and rigorous authorization checks.
- Static vs. dynamic analysis (recap)
- Static (SAST) examines code without running it; dynamic (DAST) tests the running application from the outside.
- Security unit test
- A focused automated test that verifies a single security control (e.g., that an input validator rejects bad input).
- Threat intelligence in operations
- Using external feeds of attacker tactics and indicators to tune monitoring and prioritize defenses.
- Secure update mechanism
- Delivering signed, verified updates over a protected channel so attackers cannot push malicious updates.
- Acquired software assessment
- Security-reviewing third-party or COTS software before integrating it — penetration test, SCA, and contract terms.
- Build environment hardening
- Securing the CI/CD build servers and toolchain so they cannot be used to inject malicious code into artifacts.
- Defense against logic flaws
- Business-logic vulnerabilities are missed by scanners; they require threat modeling, manual review, and abuse-case testing.
- Privacy impact assessment (PIA)
- A structured review of how a system collects and uses personal data, identifying privacy risks and required controls.
- Security requirements traceability
- Following each security requirement through design, code, and test (via the RTM) to prove it is implemented and verified.
- Defense in depth example (web app)
- WAF + input validation + parameterized queries + least-privilege DB account + encryption — layered so one failure is not fatal.
- Authenticated vs. unauthenticated scan
- An authenticated scan logs in for deeper coverage; an unauthenticated scan sees only what an outside attacker would.
- Decommission data sanitization
- At end-of-life, securely erasing or destroying data and revoking keys/credentials so nothing is recoverable.
