Security Focus Area: Context
Context determines where an application fits into the organization's ecosystem, which departments use it and for what reason, and what kinds of data it might contain. Context assessment includes Threat Modeling (which results in security stories added during Product Design iterations) and Business Impact Assessment (which results in setting correct Product Security Levels during Product Inception). Context is critical because over-engineering for security can have greater cost implications than over-engineering for scale or performance, but under-engineering can have devastating consequences.
Security Focus Area: Components
Components include libraries used by the application (selected during Product Design) and external services used (changed during Product Inception). Security review involves leveraging a library of secure design patterns and ready-to-use components defined in Golden Path/Paved Road documentation and analyzing choices through Threat Modeling. Component review must also address commercial aspects (licensing and maintenance) and usage limits.
Security Focus Area: Connections
Connections describe how to interact with an application and how it connects to components and services, where data is stored and how it is accessed, and intentional lack of connections. Connections include segregation of tiers based on Product Security Levels and potential data or environment segregation for different tenants. Adding or removing connections is probably a sign that Product Inception is happening.
Secure coding basics: Error handling
Handle errors and exceptions in a secure manner, such as by logging them securely and not disclosing sensitive information to an attacker.
Secure coding basics: Least privilege in code
Use the principle of least privilege when writing code, such that the code and the system it runs on are given the minimum access rights necessary to perform their functions.
Secure coding basics: Secure memory management
Use high-level languages recommended in Golden Path/Paved Road documentation or properly manage memory to prevent memory-related vulnerabilities such as buffer overflows and use-after-free.
Secure coding basics: Security testing
Test the software for security vulnerabilities during development and just prior to deployment.
Secure coding basics: Code auditing and reviewing
Regularly audit and review code for security vulnerabilities, such as by using automated tools or having a third party review the code.
Secure coding basics: Keeping up-to-date
Keep code up-to-date with the latest security best practices and vulnerability fixes to ensure the software is as secure as possible.
Code-level security testing integration
Integrate plausibility checks at each tier of an application (from frontend to backend) and write unit and integration tests to validate that all threats discovered during Threat Modeling have been mitigated to a level of risk acceptable to the organization. Compile use-cases and abuse-cases for each tier of the application.
Configuration security: Least Privilege
Limit the access and permissions of system components and users to the minimum required to perform their tasks.
Configuration security: Defense-in-Depth
Implement multiple layers of security controls to protect against a wide range of threats.
Configuration security: Secure by Default
Configure systems and software to be secure by default, with minimal manual setup or configuration required.
Configuration security: Secure Data
Protect sensitive data, such as personal information and financial data, by encrypting it in transit and at rest. Ensure data is correctly backed up and data retention is set correctly for the desired Product Security Level.
Configuration security: Fail Securely
Design systems to fail in a secure state, rather than exposing vulnerabilities when they malfunction.
Configuration security: Secure Communications
Use secure protocols for communication, such as HTTPS, to protect against eavesdropping and tampering.
Configuration security: Regular updates
Keep software, docker images and base operating systems up-to-date with the latest security patches. Leverage maintained hardened images where possible. This is an essential part of maintaining a secure system and references NIST SP 800-40 Rev. 4 for guidance.
Configuration security: Security Incident response plan
Have a practiced Security Incident response plan in place for how to respond to a security incident. This is essential for minimizing damage from successful attacks and is a crucial part of the Product Support Model.
OWASP TOP 10 2017 - Using Components with Known Vulnerabilities
Using Components with Known Vulnerabilities is listed as A9 in the OWASP TOP 10 2017. This is a recognized risk category for applications using third-party dependencies.
ASVS V14.2 - Dependency security requirements
The OWASP Application Security Verification Standard Project addresses dependency security under section V14.2 Dependency.
Transitive dependency vulnerability handling
When a vulnerability impacts a transitive dependency, the action must be taken on the direct dependency of the project, not on the transitive dependency itself, because acting on a transitive dependency often impacts the stability of the application. Understanding the complete relation, communication, and usage from the project's first level dependency to the impacted dependency is very time-consuming.
Responsible disclosure - CVE issuance timeline
In responsible disclosure, if a researcher does not receive a response from the vendor within 30 days, they typically proceed to full disclosure of the vulnerability.
Risk acceptance for vulnerable dependencies
When a security issue is detected in a dependency, the decision to accept the risk must be taken by the Chief Risk Officer (or Chief Information Security Officer as fallback) of the company based on technical feedback from the development team and CVSS score indicators.
Case 1: Patched version available - update and test approach
When a patched version of a vulnerable component has been released: Step 1 - Update the version of the dependency on a testing environment. Step 2 - Run tests; if all succeed, push to production; if tests fail, either update code to fit new function signatures and re-run tests, or if technical incompatibility exists (e.g., runtime version requirement), raise the issue to the provider and apply Case 2 while waiting for feedback.
Case 2: Provider delay - protective code wrapping approach
When a patched version will not be available for months: If a workaround is provided, apply and validate it on testing environment then deploy to production. If the provider gives the list of impacted functions, wrap protective code around calls to these functions to ensure input and output data safety. Web Application Firewalls (WAF) can also help through parameter validation and detection rules. Add a comment in the project README explaining the CVE is being handled during the waiting period, as detection tools will continue to raise alerts. Optionally add the dependency to the ignore list but only for the specific CVE, as a dependency can have multiple CVEs.
Case 2: Exploitation code validation step
If the provider has provided exploitation code and the team created a security wrapper around the vulnerable library, execute the exploitation code to ensure the library is now secure and does not affect the application. Then run automated unit, integration, functional, or security tests to verify the protection code does not impact application stability.
Case 2: RCE protective wrapper example in Java
Example of protective code wrapping for a Remote Code Execution vulnerability in Java: Use Pattern.matches() to validate external input against a whitelist regex (e.g., "[a-zA-Z0-9]{1,50}"). If validation succeeds, call the flawed function with safe input. If validation fails, log the exploitation attempt using SecurityLogger.warn() with the CVE number and raise an exception leading to a generic error sent to the client.
Case 3: Provider refuses to fix - patch yourself approach
When the provider refuses to fix the vulnerability, informs the team no patched version will be released, or does not answer at all: This case is complex and time-consuming and is generally a last resort. If the vulnerable dependency is open source, the development team can create a patch and submit a pull request to protect the application at the source and help others. First, consider finding an alternative better-maintained component or, for commercial components with support, apply pressure through the Chief Risk Officer or Chief Information Security Officer.
Case 3: Identifying vulnerable dependency usage
To handle a vulnerability when no patched version exists: Identify where the vulnerable dependency is used in the application using IDE built-in features or the dependency management system (Maven, Gradle, NuGet, npm, etc.). For transitive dependencies, identify the first level dependency using it. Identify all calls to the dependency in code.
Case 3: CVE analysis for patching strategy
To determine what kind of patching is needed: Analyze the CVE content, specifically the 'description' property, to identify the vulnerability type (SQL injection, Remote Code Execution, Cross-Site Scripting, Cross-Site Request Forgery, etc.). This determines the type of protective code needed and where to add it.
Case 3: XXE prevention patching example for Jackson
Example of patching strategy for CVE-2016-3720 affecting Jackson's XmlMapper: The CVE describes an XML external entity (XXE) vulnerability. The necessary patching is to add pre-validation of any XML data passed to the Jackson API to prevent XXE attacks, as documented in the XML External Entity Prevention Cheat Sheet.
Case 3: Unit test creation for vulnerability patch
Create a unit test that mimics the vulnerability to ensure the patch is effective and to continuously ensure the patch remains in place during project evolution. Run automated unit, integration, functional, or security tests to verify the patch does not impact application stability.
Case 4: Full disclosure vulnerability handling
When a vulnerable dependency is discovered via full disclosure post or penetration test and the provider is not aware: Step 1 - Inform the provider about the vulnerability by sharing the post. Step 2 - If the provider collaborates, apply Case 2; if not, apply Case 3. Instead of analyzing CVE information, analyze the full disclosure post or pentester's exploitation feedback.
Automated dependency analysis recommended from project start
It is highly recommended to perform automated analysis of dependencies from the birth of the project. Adding this task in the middle or end of the project implies a huge amount of work to handle all identified issues, imposing a burden on the development team and potentially blocking project advancement.
Vulnerable dependency detection tool - OWASP Dependency Check
OWASP Dependency Check is a free tool for detecting vulnerable dependencies. It has full support for Java and .Net, and experimental support for Python, Ruby, PHP (composer), NodeJS, C, and C++.
Vulnerable dependency detection tool - NPM Audit
NPM Audit is a free tool with full support for NodeJS and JavaScript. An HTML report is available via the npm-audit-html module.
Vulnerable dependency detection tool - OWASP Dependency Track
OWASP Dependency Track is a free tool that can be used to manage vulnerable dependencies across an organization.
Vulnerable dependency detection tool - Trivy
Trivy is a free tool with full support for Base OS, Java, NodeJS, JavaScript, Ruby, Python, Go, .NET, Rust, PHP, Dart, and Swift. It targets Kubernetes (nodes and containers), Docker (nodes and containers), filesystem, Git repositories, and cloud images.
Vulnerable dependency detection tool - Grype
Grype is a free tool with full support across mainstream language ecosystems with SBOM-driven scanning. It targets container images, filesystems, and SBOMs produced by Syft.
Vulnerable dependency detection tool - Snyk
Snyk is a commercial tool with an open source and free option available. It offers full support for many languages and package managers.
Vulnerable dependency detection tool - JFrog XRay
JFrog XRay is a commercial tool offering full support for many languages and package managers.
Vulnerable dependency detection tool - Renovate
Renovate is a commercial tool that allows detection of old dependencies. It offers full support for many languages and package managers.
Vulnerable dependency detection tool - Requires.io
Requires.io is a commercial tool with an open source and free option available that allows detection of old dependencies. It offers full support for Python only.
Vulnerable dependency detection tool selection criteria
When selecting a vulnerable dependency detection tool, ensure it: (1) Uses several reliable input sources to handle both vulnerability disclosure ways (responsible disclosure and full disclosure); (2) Supports flagging an issue raised on a component as a false-positive.
ASVS 5.0 structure and organization
The OWASP Application Security Verification Standard (ASVS) version 5.0.x is organized into 17 verification categories (V1 through V17). V1 covers Encoding and Sanitization with subsections on architecture, injection prevention, sanitization, memory/string/unmanaged code, and safe deserialization. V2 covers Validation and Business Logic. V3 covers Web Frontend Security including cookie setup and browser security headers. V4 covers API and Web Service security. V5 covers File Handling. V6 covers Authentication with subsections on password security, general authentication, factor lifecycle, multi-factor authentication, out-of-band mechanisms, cryptographic mechanisms, and identity provider authentication. V7 covers Session Management with subsections on documentation, fundamental security, timeout, termination, defenses against abuse, and federated re-authentication. V8 covers Authorization. V9 covers Self-contained Tokens. V10 covers OAuth and OIDC. V11 covers Cryptography. V12 covers Secure Communication. V13 covers Configuration. V14 covers Data Protection. V15 covers Secure Coding and Architecture. V16 covers Security Logging and Error Handling. V17 covers WebRTC.
OWASP Top Ten Proactive Controls 2018 index
The OWASP Top Ten Proactive Controls 2018 is a list of ten security techniques ordered by importance that should be included in every software development project. Control C1 (Define Security Requirements) is the most important, followed by C2 through C10.
C2 Leverage Security Frameworks and Libraries controls
C2 Leverage Security Frameworks and Libraries includes: Clickjacking Defense Cheat Sheet, DotNet Security Cheat Sheet (A3 Cross Site Scripting), PHP Configuration Cheat Sheet, Ruby on Rails Cheat Sheet (Tools and XSS), and Vulnerable Dependency Management Cheat Sheet.
C10 Handle All Errors and Exceptions controls
C10 Handle All Errors and Exceptions includes: REST Security Cheat Sheet (Error Handling) and Error Handling Cheat Sheet.
Three main authentication architecture approaches
Authentication can be handled at three main layers: Service-Level where responsibility is delegated to each service or a tightly coupled proxy, Edge-Level where authentication is centralized in a shared component at the system boundary, and Kernel-Level where authentication is performed in the operating system kernel using cryptographic identities enforced at the transport layer.
Service-Level Embedded Authentication pattern pros
Service-Level Embedded Authentication offers simplicity with fully self-contained services, customization freedom to adapt behavior to service-specific requirements, and support for both external and internal actors since the service can fully control authentication functionality.
Service-Level Embedded Authentication pattern cons
Service-Level Embedded Authentication has significant drawbacks: inconsistency in authentication behavior and flows across services, security risks from duplicated authentication code, maintenance burden when changing authentication methods, limited scalability for identity management, limited observability without centralized monitoring, complexity in authentication orchestration for multi-principal subjects, and risk of coupling external authentication data with internal trust assumptions.
Service-Level Code-Mediated Authentication pattern overview
In Service-Level Code-Mediated Authentication, services no longer verify credentials directly. Instead, an external Identity Provider (IdP) authenticates the subject and issues authentication proofs, while the service verifies these internally and extracts identity attributes for request processing.
Service-Level Code-Mediated Authentication pattern pros
Service-Level Code-Mediated Authentication enables SSO support with consolidated identity and credential lifecycle in the IdP, lower security risks from centralized authentication, improved user experience with consistent authentication flows, interoperability with widely adopted protocols like OIDC and SAML, customization freedom for service-specific needs, and support for both external and internal actors.
Service-Level Code-Mediated Authentication pattern cons
Service-Level Code-Mediated Authentication has these drawbacks: protocol handling overhead requiring each service to implement and maintain authentication proof verification logic, misconfiguration risks from incorrect verification logic such as missing expiration checks or improper cryptography use, complexity in authentication orchestration for multi-principal subjects, and risk of coupling external authentication data with internal trust assumptions.
Service-Level Proxy-Mediated Authentication pattern overview
Service-Level Proxy-Mediated Authentication offloads authentication-related logic to a dedicated proxy deployed as a sidecar alongside the service. The proxy operates in front of the application, forwards requests locally to it, performs verification of authentication proofs with the Identity Provider (IdP), and injects identity context typically via headers into requests before forwarding them to the service.
Service-Level Proxy-Mediated Authentication pattern pros
Service-Level Proxy-Mediated Authentication enables SSO support, lower security risks from centralized authentication, improved user experience, interoperability with OIDC and SAML, separation of concerns by removing authentication logic from application code, consistent behavior across services, improved security posture by consolidating logic into a hardened component, support for multiple authentication configurations and protocol chaining, and strong foundation for service-to-service trust via Zero Trust networking with workload identity using SPIFFE/SPIRE and X.509 certificates for mTLS.
Service-Level Proxy-Mediated Authentication pattern cons
Service-Level Proxy-Mediated Authentication has these drawbacks: operational complexity requiring deployment and maintenance of additional components per microservice, header spoofing risk from misconfiguration or insufficient validation allowing malicious clients or internal actors to spoof identity headers, configuration consistency requirements across all proxies, and risk of coupling external authentication data with internal trust assumptions.
Edge-Level Authentication pattern overview
In Edge-Level Authentication, authentication is handled at the system boundary by a shared component such as an API gateway or ingress proxy. This component authenticates incoming requests from external clients before they reach internal services, integrates with one or multiple Identity Providers using protocols such as OIDC, OAuth2, SAML, or mTLS, and propagates verified identity information typically via headers to downstream services.
Edge-Level Authentication pattern pros
Edge-Level Authentication provides improved consistency with uniform authentication across services at a single entry point, simplified service logic by relieving internal services from implementing authentication, faster service onboarding with minimal setup, and protocol-agnostic identity propagation using trusted formats such as newly issued JWTs or injected headers carrying identity information in protected form using standards like HTTP Message Signatures, avoiding raw external authentication data.
Edge-Level Authentication pattern cons
Edge-Level Authentication has these drawbacks: limited granularity for fine-grained or per-endpoint authentication policies such as step-up authentication, identity propagation challenges requiring secure and reliable propagation via headers with strict validation, single point of failure risk where misconfiguration or compromise impacts access and authentication decisions system-wide, and unsuitability for service-to-service authentication since it only applies to external requests and routing internal communication through the edge may introduce performance bottlenecks.