application_security/dependencies

22 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Keep npm packages up-to-date to prevent known vulnerabilities

Regularly update npm packages to patch security vulnerabilities. Use `npm audit` to check for vulnerable packages (available since npm v6). Use `npm audit fix` to automatically upgrade affected packages. Use tools like OWASP Dependency-Check and Retire.js to check for known vulnerabilities. Refer to OWASP Vulnerable Dependency Management Cheat Sheet for comprehensive tool list.

Rails dependency update process

Establish a process for updating dependencies with three mechanisms: monthly/quarterly general updates, weekly review of security vulnerabilities, and exceptional emergency updates. Rails libraries (gems) are typically unsigned; audit gems used in the project.

Self-managed services require update strategy

Self-managed tooling requires additional overhead for basic version updates, upgrades to images like AMIs or Compute Images, or other operating system level maintenance. Use automation to regularly update minor versions or images, and schedule time in development cycles for refreshing stale resources.

Hallucinated dependencies create AI-assisted typosquatting risk

AI coding assistants frequently suggest package names that do not exist on public registries. Attackers monitor for hallucinated names and register malicious packages with matching names. Developers running AI-suggested package installation commands without verification can install malicious packages.

Do: Verify AI-suggested packages before installation

Check the package page, download count, maintainer history, and creation date before installing. Be suspicious of packages with very low download counts, recent creation dates (less than 30 days), or a single maintainer with no other packages. Implement a pre-install hook or CI check that blocks installation of packages below a minimum age threshold. Maintain an internal allowlist of approved packages.

Don't: Blindly install AI-suggested packages

Do not run npm install, pip install, or go get with package names suggested by AI without verification. Do not assume that because an AI suggested a package it exists or is safe. Do not ignore typosquatting risk—AI assistants frequently suggest names that are close to real packages but slightly different.

AI models suggest outdated dependencies with known CVEs

AI models trained on historical code frequently suggest dependency versions that were current during training but now have known vulnerabilities. The AI may not know about CVEs published after its training cutoff or after the coding tool's last security-index update.

Do: Run dependency auditing on AI-generated code

Run dependency auditing tools (npm audit, pip audit, govulncheck, cargo audit) on every AI-generated dependency list before merging. Configure CI/CD pipelines to fail on known vulnerabilities regardless of whether the code was human-written or AI-generated. Pin dependencies to specific versions and update them through normal dependency management processes, not AI suggestions. Cross-reference AI-suggested versions against vulnerability databases (NVD, GitHub Advisory Database, OSV).

Don't: Accept AI-suggested dependency versions without checking

Do not accept AI-suggested dependency versions without checking for known CVEs. Do not assume that AI assistants are aware of recent vulnerability disclosures. Do not disable dependency auditing for AI-generated code.

CVE-2026-39313: mcp-framework unbounded memory allocation

mcp-framework before version 0.2.22 contains unbounded memory allocation in HTTP request body handling that allowed unauthenticated denial of service. This vulnerability highlights the need for dependency auditing and runtime limits on AI framework code.

Supply chain security for serverless: scan dependencies, use minimal packages, sign with checksums

Scan dependencies using tools such as npm audit, pip-audit, or safety. Use minimal deployment packages to reduce the attack surface. Sign packages with checksums for integrity verification.

AWS Lambda Layer hash validation with SHA-256

Verify the integrity of AWS Lambda layers using SHA-256 checksums: shasum -a 256 layer.zip.

Third-party supplier assessment criteria

Before incorporating a third-party service, product, or software component into the SSC, both the vendor and offering should be assessed for security. Component maturity, security history, and vendor response to past vulnerabilities are useful data points. For larger vendors, third-party assessments and certifications such as FedRAMP, CSA, ISO/IEC 27001, ISO/IEC 15408, or ISO/IEC 27034 provide useful information but must not be relied on exclusively.

Open-source software assessment questions

When assessing open-source projects for inclusion in SSC, consider: Is it actively maintained? Is it sufficiently popular and well-known in the applicable community? Is it sufficiently mature? Is it a release version (not alpha, beta, or comparable)? For complexity, does it have sufficient maintainers and contributors? Does it keep dependencies updated? Does it have sufficient test coverage including security-relevant rules? Is it well-documented with secure usage guidance? Does it have an established, documented vulnerability reporting process with timely fixes? Is intended usage consistent with the project's license?

Software dependency monitoring with SBOMs

Dependencies must be carefully selected before incorporation and monitored throughout the SDLC. Software Bill of Materials (SBOMs) should be used to inventory dependencies. Both production and consumption of SBOMs should be automated as part of the CI/CD process. Once dependencies are inventoried, they must be monitored for known vulnerabilities, also automated as much as possible using tools like OWASP Dependency Check or retire.js.

Vulnerability sources to monitor for dependencies

Organizations should monitor sources such as the National Vulnerability Database (NVD), OSVDB, and the CISA Known Exploited Vulnerabilities (KEV) catalog for known vulnerabilities related to dependencies used in the organization's SSC.

Lockfile and version pinning for dependencies

To reduce the likelihood that a compromised or vulnerable version is unwittingly pulled into an application, limit dependencies to specific versions that have been previously verified as legitimate and secure. This is commonly accomplished using lockfiles such as package-lock.json used by npm.

Keep dependencies up-to-date with Composer

Use Composer to keep all PHP packages and Symfony components up-to-date. Run 'composer update' to update dependencies and address known security vulnerabilities.

Symfony Security Checker scans dependencies for vulnerabilities

Symfony Security Checker examines the composer.lock file to identify any known security vulnerabilities within installed dependencies. Run the command 'symfony check:security' using Symfony CLI to check for security vulnerabilities.

RetireJS tool for identifying JavaScript libraries with known vulnerabilities

RetireJS is a free, open-source tool that helps identify JavaScript libraries with known vulnerabilities. JavaScript libraries must be kept up-to-date as previous versions can have known vulnerabilities that lead to Cross-Site Scripting (XSS) exploits. This aligns with OWASP Top 10 2013 A9 regarding the use of components with known vulnerabilities.

WebSocket libraries keep dependencies updated security advisories

Regularly update WebSocket libraries and monitor security advisories. Past versions of popular libraries (ws, Spring STOMP, Python websockets) have had critical security vulnerabilities including DoS and RCE issues.

Container security: scan images

Check container images for vulnerabilities.

Give your agent this brain