CCNA Secure Software Implementation Questions

Taint analysis tracks untrusted data flows from sources to sinks, so it can flag when sensitive values propagate into logging calls. This dataflow tracking is what detects improper handling of sensitive information in logs, unlike pattern or style checks.

An SBOM enumerates every component, library and dependency version within the software, giving the complete inventory needed to identify affected third-party libraries when a new vulnerability is disclosed. This visibility satisfies the third-party library management requirement by enabling rapid impact assessment and remediation.

Tracing untrusted input from entry points (sources) to sensitive operations (sinks) exposes injection, path traversal and deserialisation flaws that pattern-matching tools miss. This directly satisfies the stem's manual review constraint: a human follows tainted data across functions and files, confirming whether validation or encoding actually neutralises it.

Robust authentication forces callers to prove identity before reaching API logic, blocking anonymous abuse and shrinking the reachable attack surface. It is a recognised minimisation technique because unauthenticated endpoints expose parsing, business logic and data-access code to untrusted input.

Native object serialisation reconstructs arbitrary types from attacker-controlled bytes, and gadget chains in the classpath then execute during deserialisation. This language-specific mechanism, not generic parsing, is the root cause the stem's insecure deserialisation audit targets.

Pinning dependencies to exact versions with verified hashes prevents a compromised or substituted package from entering the build, blocking supply-chain attacks such as typosquatting or malicious updates that floating version ranges would silently pull in.

Storing files outside the web root prevents direct execution or rendering by the web server. Serving them with Content-Disposition: attachment forces download rather than inline display, and a safe Content-Type like application/octet-stream prevents the browser from interpreting the file as HTML or script. This effectively mitigates stored XSS because even if a malicious file is uploaded, it cannot execute in the context of the site.

Using `<%= %>` escapes HTML entities before interpolation, neutralising injected markup so browsers treat user data as text rather than executable script. This directly satisfies the XSS mitigation requirement for EJS rendering, unlike `<%- %>`, which emits raw unescaped output and permits script injection.

An HSM or KMS provides secure key storage, access control, and often key lifecycle management. Keys are never exposed in plaintext to the application; cryptographic operations are performed within the secure boundary. This is the recommended practice for protecting sensitive keys, as it prevents extraction and unauthorized use even if the application server is compromised.

Parameterised queries send SQL code and user data as separate constructs, so supplied values are bound as literals and cannot alter query structure. This removes the injection vector at the database interface regardless of input content.

Static analysis engines model pointer arithmetic and array bounds, flagging writes beyond allocated buffers. Buffer overflow is a memory-safety defect detectable from source alone, unlike runtime-only faults, so Fortify or Coverity identify it during code review before compilation or execution.

The script-src directive whitelists origins permitted to supply executable JavaScript, blocking inline and untrusted external scripts. It is the specific CSP control governing script loading sources, directly satisfying the requirement to restrict where scripts may be fetched from.

A CSPRNG is designed to produce output that is computationally infeasible to predict, even if previous outputs are known. Seeding it with a high-entropy source like /dev/urandom or CryptGenRandom ensures unpredictability. This directly satisfies the requirement for session identifiers that resist guessing attacks, as opposed to general-purpose random functions that may have predictable patterns.

The --suppression flag accepts an XML file listing false-positive identifiers, causing Dependency-Check to omit those matches from reported findings. This directly satisfies the stem's constraint of ignoring specific false-positive vulnerabilities in a third-party library without disabling broader detection.

Spring Security's HttpSecurity CSRF configuration enforces synchroniser tokens on state-changing methods (POST, PUT, DELETE), rejecting requests lacking a valid token. This directly satisfies the stem's requirement to prevent CSRF on state-changing HTTP requests in the Spring Boot application.

Mutual TLS authenticates both client and server through X.509 certificates during the TLS handshake, satisfying gRPC's requirement for strong service-to-service authentication without shared secrets. Each microservice verifies the other's certificate, providing cryptographic identity and encrypted transport, which suits machine-to-machine communication where no interactive user exists to supply credentials.

A unique per-user salt defeats rainbow tables and ensures identical passwords produce different digests, while hashing remains one-way. This satisfies the stem's requirement for the standard practice applied to all stored passwords, unlike encryption, which is reversible.

The 'state' parameter carries an opaque value the client generates and returns with the authorisation response. The client verifies it matches the value it sent, binding the response to its own request and blocking cross-site request forgery attacks that would otherwise inject a forged authorisation code.

Continuous monitoring of vulnerability disclosures for third-party libraries satisfies the stem's requirement to manage inherited risk after integration. Feeds such as the National Vulnerability Database, vendor advisories and software composition analysis alerts identify newly published CVEs affecting pinned versions, enabling timely patching before attackers exploit known flaws in deployed dependencies.

A secret management service stores the API key outside source code and injects it at runtime, removing the hardcoded credential from the repository. This satisfies the requirement to manage the secret securely, enabling rotation and access auditing.

Security requirements definition establishes the protective and compliance obligations the software must satisfy before design begins, making it an essential SSDLC component. Without it, later design, coding and testing activities lack measurable security criteria to verify against, so requirements cannot be traced or validated.

Built-in language APIs avoid invoking a shell, so user input cannot be interpreted as command syntax. This eliminates OS command injection at its source, satisfying the requirement to handle untrusted input securely rather than relying on escaping or sanitisation of shell metacharacters.

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

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

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

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

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

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

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

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

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

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