liveBook · Manning

Vulnerability

As explained in Grokking Web Application Security

A weakness in software, configuration, or system design that can be exploited to compromise security.

A vulnerability is a weakness in software, configuration, or system design that an attacker can exploit to compromise security. The practical question is not only whether your own code is safe: attackers use automated tools and scripts to find vulnerable access points, and the same tools can support either security audits or malicious attacks. section 1.1

Vulnerabilities can exist throughout a web application’s stack. Risk may come from the application server, language runtime, dependencies, libraries, web server, database, queues, caches, operating system, or virtual-machine and container services. Much of that code was written by others, so securing an application includes managing third-party risk rather than inspecting only code you wrote. section 13.0

Treat vulnerability management as an ongoing development task:

  • Discover publicly reported flaws by tracking security news and consulting the Common Vulnerabilities and Exposures (CVE) database. section 13.3
  • Compare deployed dependencies against CVE records. GitHub and GitLab can analyze dependencies automatically and highlight newly recorded vulnerabilities. section 13.3
  • Run a language-appropriate audit before committing or deploying changes; reports can identify affected dependencies, severity, and available fixes. section 13.3
  • Close weaknesses that could let attackers use your application as a stepping-stone against other systems; operational consequences can include intervention by a hosting provider. section 14.0

Checking a Node.js dependency

A Node.js application can run npm audit to compare its dependencies with known vulnerability records. The resulting report identifies vulnerable dependencies, indicates how critical each issue is, and describes how to fix it. This makes a broad concern—unknown code in a dependency tree—into a concrete patching task. section 13.3

Language

Audit tool

Python

safety (https://github.com/pyupio/safety)

Node

npm audit (http://mng.bz/BAwJ)

Ruby

bundler-audit (https://github.com/rubysec/bundler-audit)

Java

OWASP Dependency-Check (https://owasp.org/www-project-dependency-check)

.NET

NuGet (http://mng.bz/ddnQ)

PHP

local-php-security-checker (http://mng.bz/rjzX)

Go

gosec (https://github.com/securego/gosec)

Rust

cargo_audit (https://docs.rs/cargo-audit/latest/cargo_audit)

Use the audit-tool table to choose a dependency scanner for Python, Node, Ruby, Java, .NET, PHP, Go, or Rust. section 13.3

How Grokking Web Application Security covers it

How deep it goes
Explains stack-wide third-party exposure and dependency-audit workflows, without detailing individual exploit mechanisms.
Examples
Uses Apache Tomcat disclosure, GitHub and GitLab dependency alerts, npm audit, and a cross-language audit-tool table.
What it assumes
Assumes a web application with dependencies and source control while introducing vulnerability discovery in practical terms.
What you can do after
Operate/configure dependency-audit tooling to identify vulnerable dependencies, assess reported criticality, and apply available fixes.
How it connects
Connects vulnerabilities with penetration testing, CVE records, dependency management, configuration, and third-party code.

Also explained in

Compare how 16 books explain vulnerability →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Grokking Web Application Security. The section links point to the parts of the book it draws on.