Software Development Security practice questions

Vulnerability scanner

Why it fails: Vulnerability scanners primarily identify known security weaknesses in systems, networks, or applications by comparing configurations and observed behaviors against a database of signatures. While they can detect outdated software versions that might imply certain components, their core function is not to enumerate a comprehensive, hierarchical list of all third-party and open-source components and their dependencies within a software product. Therefore, it cannot fulfill the requirement of understanding the full software supply chain composition.

Static Application Security Testing (SAST)

Why it fails: Static Application Security Testing (SAST) tools analyze an application's source code, bytecode, or binary code without executing it, identifying potential security flaws like buffer overflows or SQL injection vulnerabilities. While SAST can sometimes identify specific libraries or frameworks used by parsing manifest files or import statements, its primary purpose is not to generate a complete, hierarchical inventory of all direct and transitive third-party and open-source components, including their versions and licenses, which is crucial for comprehensive supply chain risk management.

Dynamic Application Security Testing (DAST)

Why it fails: Dynamic Application Security Testing (DAST) tools interact with a running application from the outside, simulating attacks to identify runtime vulnerabilities such as cross-site scripting or authentication bypasses. Because DAST operates on the compiled, executing application and does not access its internal source code or build artifacts, it cannot systematically enumerate the specific third-party libraries, open-source components, or their dependencies embedded within the application. Its focus is on observable behavior and exploitable flaws, not internal component composition.

Strong authentication

Why it fails: Strong authentication refers to the use of robust methods and controls to verify a user's identity, making it significantly harder for unauthorized individuals to gain access. Implementing an account lockout policy directly strengthens authentication by preventing attackers from making unlimited login attempts, thereby mitigating brute-force and credential stuffing attacks. This mechanism enhances the overall security posture of the authentication process by limiting the window of opportunity for attackers.

Defense in depth

Why it fails: Defense in depth is a cybersecurity strategy that employs multiple, overlapping security controls to protect assets, ensuring that if one control fails, others are still in place to provide protection. It involves layers like physical, technical, and administrative safeguards. While account lockout is a technical control, it represents a single mechanism within the authentication layer, rather than a multi-layered architectural approach encompassing diverse security domains.

Least privilege

Why it fails: The principle of least privilege dictates that users, processes, or systems should be granted only the absolute minimum set of permissions necessary to perform their legitimate tasks, and no more. This minimizes the potential damage if an account is compromised. Account lockout, conversely, is an authentication mechanism designed to prevent unauthorized access attempts altogether, and it does not define or restrict the specific access rights a successfully authenticated user possesses.

Implementing input validation on deserialized data

Why it fails: Implementing input validation on data *after* it has been deserialized is insufficient to prevent deserialization attacks. Many deserialization vulnerabilities exploit the process itself, allowing malicious code to execute during the object's construction or method calls triggered by the deserializer, *before* any application-level validation logic can be applied to the resulting object's state. By the time validation occurs, the damage, such as remote code execution or arbitrary file writes, may have already been done, making this a reactive and often ineffective control against the core deserialization exploit.

Using a allowlist of classes allowed to be deserialized

Why it fails: While using an allowlist of permitted classes for deserialization is a valuable security measure to prevent the instantiation of arbitrary or unexpected classes, it does not fully mitigate all deserialization vulnerabilities. Attackers can still exploit 'gadgets' within *allowlisted* classes, chaining their methods to achieve malicious outcomes like remote code execution or denial of service. The vulnerability often lies in the interaction and side effects of legitimate methods within trusted classes when invoked during deserialization with attacker-controlled data, rather than merely the presence of an unauthorized class.

Running deserialization in a sandboxed environment

Why it fails: Running deserialization within a sandboxed environment can limit the *impact* of a successful deserialization attack by restricting the resources and permissions available to the deserialized object and its associated code. However, sandboxing does not *prevent* the initial exploitation or the execution of malicious code within the sandbox itself. An attacker could still achieve denial of service, information disclosure, or even sandbox escape if vulnerabilities exist, making it a containment strategy rather than a primary preventative measure against the deserialization vulnerability itself.

Using short session timeouts

Why it fails: Short timeouts reduce the window of attack but do not prevent fixation.

Setting the secure flag on cookies

Why it fails: Secure flag ensures cookies are sent over HTTPS only, but does not prevent fixation.

Implementing HTTPS for all communications

Why it fails: HTTPS protects data in transit but does not prevent session fixation.

Verifying software license compliance

Why it fails: While essential for legal and contractual adherence, verifying software license compliance primarily addresses intellectual property rights and contractual obligations rather than the inherent security of the software itself. This activity ensures the acquiring organization adheres to the terms of use, preventing legal repercussions or financial penalties. However, it does not directly assess or improve the security posture, vulnerability profile, or operational resilience of the acquired software product, making it distinct from direct security assessment activities.

Ensuring code signing is used in the vendor's development process

Why it fails: Ensuring code signing is used in the vendor's development process is a specific technical control for maintaining software integrity, but it is not a primary initial acquisition assessment activity. Code signing cryptographically verifies the authenticity and integrity of software, confirming it has not been tampered with since its release by the developer. While crucial for deployment and runtime security, this is a post-development control that verifies the software's state at release, rather than assessing the inherent vulnerabilities within the code or the vendor's broader security practices during the initial acquisition phase.

Implement CSRF tokens for all state-changing requests.

Why it fails: Cross-Site Request Forgery (CSRF) tokens are crucial for preventing attackers from tricking authenticated users into executing unintended actions on a web application. While CSRF is a form of tampering, it primarily addresses tampering at the application layer by ensuring requests originate from the legitimate user interface, not from a malicious third-party site. The question's context, however, emphasizes "tampering in transit" and "information disclosure," which are better addressed by transport layer security mechanisms like TLS, making CSRF tokens less directly relevant to the specific threats highlighted.

Log all user credentials during authentication attempts for audit purposes.

Why it fails: Logging user credentials, such as usernames and passwords, during authentication attempts creates a severe information disclosure vulnerability. If these logs are compromised, an attacker would gain direct access to sensitive user authentication data, leading to account takeovers and further breaches. Best practice dictates logging only non-sensitive information, like timestamps, source IP, and authentication success or failure, to maintain audit trails without introducing an unacceptable risk of credential exposure.

Deploy a Web Application Firewall (WAF) to block all incoming traffic from unknown IP addresses.

Why it fails: While a Web Application Firewall (WAF) is effective at mitigating various application-layer attacks like SQL injection and Cross-Site Scripting (XSS), blocking all incoming traffic from "unknown IP addresses" is an overly broad and impractical security measure. This approach would severely disrupt legitimate user access and is not a primary function or effective configuration for a WAF, which typically focuses on inspecting and filtering malicious request patterns rather than IP reputation alone. Furthermore, this does not directly address information disclosure or tampering in transit as effectively as other controls.

Implement a Web Application Firewall (WAF) rule to block known exploits targeting the library.

Why it fails: A WAF can block known attack patterns, but it cannot remediate vulnerabilities within the library itself. Attackers may bypass WAF rules using obfuscation or new exploit variants. This approach is reactive and does not address the root cause—unpatched code—making it less effective than taking ownership of the code.

Restrict the library to non-production environments until a replacement is found.

Why it fails: Restricting to non-production avoids risk in production but does not allow the team to deliver the desired UI features to customers. It also leaves the risk unmanaged if the library is eventually used. This is a temporary workaround, not a control that effectively manages the risk while maintaining functionality.

Require developers to manually review the library's source code before each release.

Why it fails: Manual code review can find some issues, but it is not a scalable or reliable control for an unmaintained library. Vulnerabilities may be subtle or require specialized knowledge. Without a process to patch and maintain the code, this does not provide ongoing protection, making it less effective than forking and patching.

Escaping all user input before concatenation

Why it fails: Escaping all user input before concatenation is an unreliable defense against SQL injection due to its inherent complexity and potential for errors. Developers must correctly identify and escape all context-specific special characters, which is difficult to do exhaustively across various database systems and encoding schemes. A single missed character or incorrect escaping rule can create a vulnerability, making it a brittle and high-maintenance approach that is prone to bypasses.

Input validation using a blacklist of known malicious patterns

Why it fails: Input validation using a blacklist of known malicious patterns is fundamentally flawed because it operates on an incomplete and reactive basis. Attackers can often bypass blacklists by employing novel attack techniques, using different encodings, or discovering patterns not included in the list. This approach creates a false sense of security and requires constant, exhaustive updates to remain even marginally effective, which is practically unsustainable.

Implementing a Web Application Firewall (WAF)

Why it fails: Implementing a Web Application Firewall (WAF) acts as a valuable compensating control, but it does not comprehensively prevent application-layer vulnerabilities like SQL injection at the source. While a WAF can detect and block many common attack signatures, it operates at the network perimeter and cannot fix insecure application code. It may be bypassed by sophisticated attackers, generate false positives, or miss zero-day exploits, making it a secondary defense rather than a primary solution for secure coding practices.

Information Disclosure

Why it fails: Information Disclosure, in the context of an online banking application, refers to the unauthorized exposure of sensitive or confidential data to individuals or systems not permitted to access it. This could involve leaking account balances, transaction histories, personal identifiable information (PII), or even system architecture details, thereby compromising the confidentiality of user data and operational security. While a critical threat, it doesn't directly describe the *alteration* of data.

Elevation of Privilege

Why it fails: Elevation of Privilege occurs when an attacker exploits a vulnerability to gain access rights or permissions beyond what they were initially authorized for, moving from a lower-privileged state to a higher one. In an online banking scenario, this might involve a regular user gaining administrative access or a limited user gaining access to another user's full account. While a severe threat, it focuses on unauthorized *access levels* rather than the direct *modification of data* itself.

Spoofing

Why it fails: Spoofing involves an attacker successfully impersonating a legitimate user, system, or entity to gain unauthorized access or deceive other components within the online banking environment. This could include phishing attacks to steal credentials, IP address spoofing, or DNS spoofing, aiming to bypass authentication mechanisms or misdirect traffic. Its primary focus is on faking identity or origin, distinct from the direct unauthorized alteration of data.

Use Content Security Policy (CSP) headers to restrict script execution

Why it fails: While Content Security Policy (CSP) headers are a valuable defense-in-depth mechanism, they operate client-side to mitigate the *impact* of XSS by restricting script execution. CSP cannot retroactively fix the underlying server-side vulnerability where malicious scripts are already stored in the database. The core issue of untrusted data being stored and later rendered unsafely remains unaddressed by CSP alone, making it an incomplete solution for remediation.

Sanitize input by removing all HTML tags before storing

Why it fails: Removing all HTML tags during input sanitization is an overly aggressive approach that can severely degrade legitimate user functionality, such as allowing rich text formatting. While input validation is crucial, simply stripping tags does not guarantee XSS prevention if other attack vectors exist, and it fundamentally alters the user's intended content. Furthermore, this method is less robust than context-aware output encoding, which preserves data integrity while neutralizing malicious script execution upon rendering.

Store comments in a separate domain to isolate them

Why it fails: Storing comments on a separate domain, while potentially a good security practice for isolating user-generated content, does not directly prevent a stored Cross-Site Scripting (XSS) vulnerability. If the separate domain still renders the unsanitized malicious content, the XSS payload will execute within that isolated domain's context. This strategy primarily aims to limit the *blast radius* of an attack by preventing session hijacking or data exfiltration from the main application's domain, rather than eliminating the XSS flaw itself.

Separation of duties

Why it fails: This principle is an administrative control designed to mitigate the risk of fraud, error, and insider threat by distributing critical tasks among multiple individuals. It ensures that no single person possesses sufficient privileges to complete a sensitive operation entirely on their own, requiring collusion to bypass controls. While vital for governance, it does not directly address the architectural layering of diverse technical security mechanisms to protect against external attacks.

Fail-secure

Why it fails: The fail-secure principle dictates that when a system component experiences a failure, it should default to a state that denies access or operation, thereby preserving the confidentiality, integrity, and availability of data. This prevents unauthorized access or exploitation during system malfunctions. However, this principle specifically addresses system behavior upon failure rather than the proactive, multi-layered deployment of diverse security mechanisms intended to prevent initial compromise.

Least privilege

Why it fails: The principle of least privilege mandates that every user, program, or process should be granted only the minimum necessary permissions and access rights required to perform its specific authorized functions. This significantly reduces the potential impact of a security breach or error by limiting the scope of damage an attacker or compromised entity can inflict. While crucial for minimizing the attack surface, it focuses on access control granularity rather than the strategic deployment of multiple, distinct security layers throughout an entire system.

Broken authentication

Why it fails: Broken authentication refers to vulnerabilities in how an application manages user identities, login credentials, and session tokens. This could manifest as weak password policies, improper session invalidation, or susceptibility to brute-force attacks. While critical for overall security, it doesn't directly describe a scenario where an authenticated user can access another user's resources simply by changing an object identifier in a request without proper authorization checks.

Server-side request forgery (SSRF)

Why it fails: Server-side request forgery (SSRF) is a vulnerability where an attacker can induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing. This allows the attacker to force the server to connect to internal services within the organization's infrastructure or external third-party services. This differs from IDOR, which focuses on unauthorized direct access to application objects by manipulating identifiers, rather than coercing the server to initiate new, unauthorized network connections.

Security misconfiguration

Why it fails: Security misconfiguration encompasses a broad range of vulnerabilities resulting from improperly configured security settings across the application stack, including web servers, application servers, databases, and frameworks. Examples include using default credentials, enabling unnecessary features, verbose error messages revealing sensitive information, or inadequate access controls on directories. While IDOR can sometimes stem from a misconfiguration of authorization rules, the core issue of directly referencing objects without proper checks is more specifically categorized as IDOR itself, rather than a general misconfiguration.

Encoding input before processing

Why it fails: Encoding input before processing is an incorrect security practice for input validation. Encoding transforms special characters into a safe representation for a specific context, like HTML entities or URL encoding, but it does not validate the input's intent or content. A malicious payload, even if encoded, can still be decoded and executed by the application or underlying interpreter if it's not properly validated against expected patterns *before* any processing occurs. This approach merely shifts the problem without addressing the root cause of untrusted input.

Using regular expressions to sanitize input

Why it fails: Regular expressions for input sanitisation attempt to remove or block malicious characters, but injection attacks exploit context-specific parsing (e.g., SQL, LDAP, or shell interpreters) that regex cannot reliably anticipate across all encoding layers. This approach is tempting because regex effectively validates format constraints (e.g., email patterns) in static data, where character whitelisting is sufficient. It would be correct for preventing format-based injection in a single, well-defined context like a numeric ID field.

Blacklist validation to block known malicious patterns

Why it fails: Blacklist validation, which attempts to block known malicious patterns, is inherently flawed and provides insufficient security. This reactive approach relies on maintaining an exhaustive list of all possible bad inputs, which is practically impossible to achieve. Attackers can often bypass blacklists by using novel attack vectors, different encodings, or obfuscation techniques not present in the predefined list, leaving the application vulnerable to new or cleverly disguised threats. It creates a false sense of security by focusing on what *not* to allow, rather than what *is* allowed.

Insecure direct object reference (IDOR)

Why it fails: IDOR occurs when an application exposes a direct reference to an internal object—such as a file, database record, or account ID—and fails to verify that the requesting user is authorized to access that specific object. In this scenario the attacker isn't manipulating an object reference; they're coercing the server itself into issuing requests to other internal hosts via a URL parameter, which is a server-side trust boundary failure, not a missing authorization check on a user-owned resource.

Remote code execution (RCE)

Why it fails: Remote code execution means an attacker gets the server to execute arbitrary commands or code they supply, typically through an unsafe deserialization, injection, or file-upload flaw. Nothing in this scenario shows the attacker running code on the server—they're only causing the server to make outbound HTTP requests to internal addresses on their behalf. Triggering unintended network requests is a distinct vulnerability class from achieving code execution, even though a chained SSRF could sometimes lead to RCE in specific environments.

Cross-site request forgery (CSRF)

Why it fails: CSRF tricks an already-authenticated victim's browser into submitting a state-changing request to an application without their consent, exploiting the browser's automatic inclusion of session cookies. That requires a human victim's browser and session to be involved. Here, the attacker is directly manipulating a URL parameter to make the server itself issue requests, with no victim browser, session hijacking, or cross-site request forwarding taking place, so it doesn't fit the CSRF pattern.

Display detailed errors to users for troubleshooting

Why it fails: Exposing detailed error messages directly to users, such as full stack traces, SQL error messages, or internal file system paths, provides attackers with invaluable reconnaissance data. This information can reveal the application's underlying technologies, database structure, and potential vulnerabilities, enabling them to craft more targeted and effective exploits. Such disclosures significantly increase the attack surface and can lead to serious security breaches, including data exfiltration, privilege escalation, or remote code execution by providing a roadmap to system internals.

Disable all error reporting to eliminate information leakage

Why it fails: Completely disabling all error reporting creates a dangerous blind spot, preventing administrators from detecting and diagnosing critical application failures or security vulnerabilities in a timely manner. While it might seem to eliminate information leakage, it merely hides problems, allowing silent failures to persist, potentially leading to data corruption, service outages, or unpatched security flaws that attackers could still discover and exploit through other means. This approach severely hampers incident response capabilities and overall system resilience, making it impossible to address issues proactively.

Encrypt error messages before displaying to users

Why it fails: Encrypting error messages before displaying them to users offers no practical security benefit against information leakage if the user, or an attacker impersonating a user, possesses the means to decrypt the message. The core problem of sensitive data disclosure remains unaddressed, as the information is merely obfuscated rather than truly protected from the intended recipient. This method introduces unnecessary computational overhead and complexity without mitigating the fundamental risk of exposing internal system details to anyone who can access and decrypt the message.

Encrypt passwords using AES-256 with a static key

Why it fails: Encrypting passwords using AES-256 with a static key is fundamentally insecure for password storage because encryption is a reversible process. If the single static encryption key is ever compromised, all stored passwords can be immediately decrypted and exposed in plaintext. This method offers no protection against an attacker who gains access to both the encrypted data and the key, making it unsuitable for safeguarding sensitive user credentials.

Store passwords in plaintext but in a protected database

Why it fails: Storing passwords in plaintext, even within a supposedly protected database, is an unacceptable security practice. While database protections like access controls and firewalls are important, they are not infallible. Any successful breach of the database's perimeter defenses, whether through SQL injection, insider threat, or zero-day exploit, would instantly expose all user passwords without any cryptographic barrier, leading to widespread account compromise and potential identity theft.

Hash passwords with SHA-256 without salt

Why it fails: Hashing passwords with SHA-256 without a salt is highly vulnerable to various attacks, primarily rainbow tables and dictionary attacks. Without a unique salt, identical passwords will always produce the exact same hash value. Attackers can precompute a vast database of common password hashes (a rainbow table) and quickly match stolen hashes to their corresponding plaintext passwords, bypassing the need for individual brute-force attempts and compromising user accounts efficiently.

Injection

Why it fails: Injection vulnerabilities occur when untrusted data is sent to an interpreter as part of a command or query, tricking the interpreter into executing unintended commands or accessing unauthorized data. This category includes SQL Injection, NoSQL Injection, OS Command Injection, and Cross-Site Scripting (XSS), where malicious input manipulates the application's underlying logic or data interactions. It specifically targets how an application processes and executes user-supplied input.

Cryptographic Failures

Why it fails: Cryptographic Failures involve the improper implementation or absence of cryptographic protections, leading to the exposure of sensitive data. This can manifest as using weak or deprecated algorithms, insufficient key lengths, improper key management, or failing to encrypt data at rest or in transit when required. Such failures directly compromise the confidentiality and integrity of protected information, making it readable or modifiable by unauthorized parties.

Broken Access Control

Why it fails: Broken Access Control refers to the improper enforcement of restrictions on what authenticated users are allowed to do, allowing them to bypass authorization checks. This can enable users to access other users' accounts, view sensitive files, modify data, or perform administrative functions without proper permissions. Flaws often arise from incorrect role-based access control (RBAC) implementations or insufficient validation of user requests against their assigned privileges.

Regenerate session tokens after login

Why it fails: Regenerating session tokens after login is primarily used to prevent session fixation attacks, where an attacker sets a known session ID before authentication. It does not directly address session token predictability, exposure in URLs, or absence of logout invalidation, making it less appropriate for the listed issues.

Implement IP address binding for session tokens

Why it fails: Implementing IP address binding for session tokens attempts to tie a session to a specific client IP address, but it introduces significant usability issues for legitimate users whose IP addresses may change during a session (e.g., mobile users, VPNs, or users behind load balancers). Furthermore, this control can often be bypassed by sophisticated attackers using proxies, botnets, or by compromising the user's local network, making it an unreliable and often counterproductive security measure.

Penetration testing

Why it fails: Penetration testing involves authorized simulated attacks on a system to identify exploitable vulnerabilities and assess the overall security posture. While crucial for validating defenses, it is typically a resource-intensive, manual process performed at later stages of the development lifecycle or on deployed systems. Its nature makes it unsuitable for continuous integration into early development and testing phases.

Vulnerability scanning

Why it fails: Vulnerability scanning systematically identifies known security weaknesses in networks, servers, and applications by comparing system configurations and installed software against a database of known vulnerabilities. While important for overall security posture, it primarily focuses on infrastructure and common software flaws, rather than deep analysis of custom application code during its development. It's generally an external, post-development assessment.

Dynamic Application Security Testing (DAST)

Why it fails: DAST examines a running application from the outside, simulating an attacker's perspective by sending various inputs and observing the application's responses. It can identify runtime vulnerabilities like authentication flaws or configuration errors. However, DAST requires a fully functional and deployed application instance, making it more suitable for later stages of the SDLC, such as quality assurance or pre-production environments, rather than continuous integration during early development.

CVSS

Why it fails: CVSS (Common Vulnerability Scoring System) is a standardized, open framework for communicating the characteristics and impacts of IT vulnerabilities. It provides a numerical score representing the severity of a vulnerability, allowing organizations to prioritize remediation efforts. However, CVSS is a post-discovery scoring system for *existing* vulnerabilities, not a proactive methodology for identifying potential threats during the design or requirements gathering phases of software development.

OCTAVE

Why it fails: OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) is a comprehensive risk-based strategic assessment and planning framework, not a specific threat modeling methodology focused on software design categories. It helps organizations understand information security risks by identifying critical information assets, the threats to those assets, and the vulnerabilities that could expose them. OCTAVE focuses on organizational risk management and developing a protection strategy rather than detailing specific software-level threats like Spoofing or Tampering.

PASTA

Why it fails: PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage, risk-centric threat modeling methodology that provides a structured approach to identifying, enumerating, and scoring threats. While it is a robust framework for understanding potential attacks and their business impact, it is distinct from STRIDE's specific categorization of threats against system properties. PASTA emphasizes an attacker-centric view, focusing on attack simulation and risk analysis to derive appropriate countermeasures, rather than a direct classification of threats into categories like Spoofing or Elevation of Privilege.