Source Code Vulnerability Management

Objectives: By the end of this topic, you will be able to…

Detect common vulnerabilities in real source code

Use static analysis tools to automate code review

Apply critical thinking to interpret and validate findings

Propose secure improvements to the code

What is a vulnerability in code?

A source code vulnerability is a weakness in the logic or implementation of software that can be exploited to compromise its confidentiality, integrity, or availability. These flaws may allow an attacker to execute malicious code, access sensitive information, or alter the system’s behavior.

Main causes of vulnerabilities

Logical errors: the program’s logic does not consider all possible scenarios. Example: validating authenticated users but not verifying roles before sensitive actions
Lack of input validation: uncontrolled input can cause injections, logic failures, or leaks. Example: not using escape functions to prevent SQL injection
Use of insecure functions: some functions do not control data size or lack error handling. Example: strcpy in C (can cause buffer overflow)
Insecure credential management: hardcoding keys, tokens, or passwords; using weak cryptographic algorithms
Access control errors: not properly restricting access to resources; confusing authentication (identity) with authorization (permissions)

Relevant OWASP Top 10 categories

The OWASP Top 10 lists the most critical web application vulnerabilities. Those most related to source code:

Category	Description	Example
A01 — Broken Access Control	Unauthorized access to functions or data	IDOR (Insecure Direct Object Reference)
A03 — Injection	SQL, OS command, or other injection	Inadequate input validation
A07 — Auth Failures	Authentication or session management failures	Token reuse, weak passwords
A08 — Integrity Failures	Using compromised dependencies without verification	Libraries without hash checks
A09 — Logging Failures	Not logging relevant events	Ongoing attacks undetected
A10 — SSRF	User-controlled destination in outbound requests	Internal network scanning

Static vs dynamic analysis

SAST (Static Application Security Testing)

Performed without executing the program
Examines source or binary code for risky patterns
Detects injections, information leaks, validation errors, insecure functions

Advantages: integrates into CI/CD, detects flaws early, reduces remediation costs. Limitations: may generate false positives, cannot verify runtime behavior.

Dynamic analysis (DAST or IAST)

Performed by running the application and observing behavior
Useful for detecting vulnerabilities that only appear at runtime
Complements static analysis

SAST tools

Tool	Language	Description
`Bandit`	Python	Reviews code for insecure practices
`Semgrep`	Multi-language	Lightweight, customizable pattern detection
`Flawfinder`	C/C++	Classic tool for insecure function detection
`SonarQube`	Multi-language	Supports custom rules, quality + security
`CodeQL`	Multi-language	Complex pattern queries on code (GitHub)
`Brakeman`	Ruby on Rails	Analysis for Rails applications
`ESLint + Security Plugins`	JavaScript/TypeScript	Security-focused linting

These tools are often integrated into CI/CD pipelines to automatically scan code on each commit or pull request.

Interpreting and validating findings

Prioritize by severity and context: not all findings represent a real risk. Evaluate if the vulnerable code is truly exposed
Reproducibility: can the finding be exploited? Under what conditions?
Data flow context: verify if input reaches critical functions without proper validation
Secure refactoring: fix the flaw applying secure coding principles without breaking logic
Document and report: each finding should be documented for review, correction, and learning

Hands-on lab

Requirements: Kali Linux, bandit, flawfinder, semgrep, Node.js

Part 0: Setting up the lab

# Install pipx
sudo apt install pipx
 
# Install scanner tools
pipx install bandit flawfinder semgrep

Create a Semgrep account at semgrep.dev using your GitHub account.

Part 1: Automated Python analysis with Bandit

Run against the provided insecure_script.py:

bandit -r insecure_script.py

Analyze the report: types of issues, severity, how to fix
Correct the code securely, adding comments for changes

Part 2: C code analysis with Flawfinder

Run against the provided vulnerable.c:

flawfinder vulnerable.c

Identify dangerous functions, critical lines, associated risk
Discuss mitigations: use of safe functions (fgets, snprintf), input validation

Part 3: Manual code review

Review the provided InsecureSnippet.java
Identify: lack of input validation, sensitive data exposure, insecure functions, injection points
Document each finding:

Line	Detected vulnerability	Risk	Proposed fix
12	Use of `eval(user_input)`	RCE	Replace with `ast.literal_eval()`
30	`strcpy(dest, src)` without check	Buffer overflow	Use `strncpy()` with limit

Part 4: Using semgrep on web code

Extract provided Node.js/Express project
Install dependencies and run the app:

npm install
npm start

Run semgrep:

semgrep --config=auto path/to/code

Compare automated results with manual review

Submission

Compressed folder including:

Screenshots from Bandit, Flawfinder, and Semgrep
Corrected and commented code
Table of manual findings with justification
Written reflection (max. 1 page)

Key concepts

Term	Definition
SAST	Source code analysis without executing the application
Vulnerability	Exploitable weakness in a system or application
SQLi	Injection of malicious SQL code into input fields
XSS	Injection of malicious scripts into web pages
Bandit	SAST tool for Python code
Semgrep	Multi-language and customizable static analyzer
OWASP Top 10	List of the ten most critical web vulnerabilities

Test yourself

OWASP: Given a web form that receives a username and inserts it directly into a SQL query, which OWASP Top 10 category applies? How would you fix it?
Tools: What is the difference between what a SAST tool detects and what a human reviewer can find? What types of vulnerabilities escape automated tools?
Practice: Why is it important to run static analysis on every commit within a CI/CD pipeline, rather than only before releasing to production?

Navigation: ← Previous | Home | Next →

Quartz 4

Explorer

08 - Source Code Vulnerability Management