Cybersecurity Roadmap

Learn how to secure networks, applications, and systems against digital threats.

Overall Progress0%

Secure Coding & SAST

Explanation

Secure coding is writing software so that it is hard to misuse: validating input, encoding output, parameterizing queries, checking authorization, and failing safely. Static Application Security Testing (SAST) and related tooling catch these mistakes early, in the development workflow, before they reach production. This lesson covers the principles of security by design, the specific coding patterns that prevent common vulnerabilities, and the tooling — SAST, DAST, and SCA — that automates finding them, plus how false positives and false negatives shape remediation. The code examples are deliberately vulnerable then fixed, using small, self-contained Python so you can see the exact difference.

Security by Design

Treat security as a requirement from the start, not a review at the end.
Model threats during design so controls are built in.
Prefer secure defaults over optional hardening.
Assume every input is hostile and every boundary is crossed.

Input Validation and Output Encoding

Validate with allowlists: accept only what you expect.
Validate at trust boundaries (every external input).
Encode output for its context to prevent injection.

Parameterized Queries

python

1# Vulnerable: string concatenation2query = "SELECT * FROM users WHERE name = '" + name + "'"3 4# Secure: parameterized / prepared statement5query = "SELECT * FROM users WHERE name = %s"6cursor.execute(query, (name,))

Parameterized queries separate code from data so the database never interprets input as SQL.

Authentication and Authorization Checks

Store only hashed passwords with a slow, salted algorithm.
Check authorization on the server for every sensitive operation.
Do not trust client-side checks or hidden fields.

Least Privilege and Secrets Management

Run with the least privilege needed; avoid root/admin.
Store secrets in a secrets manager, never in code or config committed to source control.
Rotate credentials and use short-lived tokens where possible.

Error Handling and Logging

Return generic errors to users; log details server-side.
Never leak stack traces, queries, or secrets in errors.
Log security-relevant events but never log secrets.

Dependency Security (SCA)

Software Composition Analysis scans third-party dependencies for known vulnerabilities.
Pin versions and update regularly.
Review the supply chain: only pull from trusted sources.

Secure Defaults and Fail-Safe Behavior

Default to deny; require an explicit allow.
Fail closed: on error, deny rather than allow.
Avoid insecure defaults such as weak crypto or open permissions.

Defensive Programming

Check preconditions and reject invalid state early.
Handle unexpected values gracefully rather than crashing into an insecure state.
Write small, reviewable units that are easy to reason about.

Threat Modeling During Development

Identify assets and entry points.
List threats (e.g., STRIDE).
Prioritize by likelihood and impact.
Apply mitigations and verify them.

SAST vs DAST vs SCA

Tool	Analyzes	When it runs	Finds
SAST	Source code / bytecode	During development/CI	Injection, hardcoded secrets, unsafe patterns
DAST	A running application	Against a deployed/test instance	Runtime flaws, misconfigurations, exposed endpoints
SCA	Third-party dependencies	During build	Known vulnerabilities in libraries

SAST looks at code, DAST tests the running application, and SCA checks dependencies. They are complementary, not interchangeable.

Secret Scanning, Code Review, and Security Gates

Secret scanning detects credentials and tokens in code and history.
Code review includes a security lens, not just correctness.
Security gates in CI/CD block deployment when a critical finding is present.

CI/CD Security and DevSecOps

Shift security left: scan in the pipeline, not after release.
Run SAST/SCA/secret scanning automatically on every change.
Sign and pin build artifacts and images.
Apply the same least privilege to pipeline credentials.

Vulnerability Lifecycle and Remediation

Triage findings by severity and exploitability.
False positive: a flagged issue that is not real.
False negative: a real issue the tool missed.
Remediate by risk, not by raw count.
Verify the fix and retest.

Syntax

Vulnerable → fixed: SQL and command handlingpython

1# Vulnerable: string-built SQL2query = "SELECT * FROM users WHERE id = " + user_id3 4# Secure: parameterized5query = "SELECT * FROM users WHERE id = %s"6cursor.execute(query, (user_id,))7 8# Vulnerable: shell=True with user input9subprocess.call("ping " + host, shell=True)10 11# Secure: argument list, no shell12subprocess.call(["ping", host])

Passing an argument list (instead of a single shell string) prevents the shell from interpreting user input as commands.

Examples

Output encoding prevents XSS

Rendering untrusted text safely.

python

1import html2user_text = "<script>alert(1)</script>"3print(html.escape(user_text))

Output

&lt;script&gt;alert(1)&lt;/script&gt;

Choosing the right scanner

A bug in a dependency is invisible to SAST.

text

1Dependency vulnerability → SCA (not SAST)2Live endpoint exposure  → DAST (not SAST)3Hardcoded secret in code → SAST / secret scanning

Output

(match the tool to the layer it analyzes)

Key Takeaways

Validate input, encode output, and parameterize queries.
Enforce authorization and least privilege on the server.
SAST analyzes code, DAST tests running apps, SCA checks dependencies.
Scan in CI/CD and block critical findings with security gates.
Handle errors without leaking internals; never log secrets.
Triage by risk and distinguish false positives from false negatives.

← PreviousWeb Application Security Next →Penetration Testing