Secure Software Design

Today’s Agenda
1. Code Security testing and review methods
2. Description , tools , advantages and
disadvantages of each
3. SAST ?
 Code Security Review
• Used for identifying , assessing and mitigating
vulnerabilities in software system
• Helps ensure the code is secure against potential
attacks and follow best practices for secure coding
 Code Security testing methods
• SAST
• DAST
• Manual code review
• Peer code review
• Fuzz testing
• Penetration testing
• Security Unit testing
• IAST
• SCA
• Security Regression testing
 Static Code Analysis (Static Application Security Testing - SAST)

• Analyzing the source code without executing it to detect

vulnerabilities such as insecure coding practices, potential
buffer overflows, SQL injection risks, and other issues.
• Tools:
SonarQube
Checkmarx
Veracode
1. Fortify
2. Identifies issues early in the development process.
3. Can be automated and integrated into CI/CD pipelines.
4. Covers a wide range of security flaws (e.g., injection flaws,
improper error handling).
May produce false positives.
Limited to detecting certain types of vulnerabilities that can be
identified in the code itself (not in runtime).
 Dynamic Code Analysis (Dynamic Application
Security Testing - DAST)

• Analyzing the running application to identify security

vulnerabilities. This involves interacting with the
application to uncover issues like authentication
problems, insecure APIs, and misconfigurations.
• Tools:
– OWASP ZAP
– Burp Suite
– Acunetix
– Netsparker
1. Finds vulnerabilities in a running application (runtime
flaws, logic errors, configuration issues).
2. Can simulate real-world attacks.
May miss vulnerabilities that only static analysis can detect.
Cannot be performed until the code is in a deployable state.
 Manual Code Review
• Security experts or developers manually inspect the
source code to identify vulnerabilities, insecure design
patterns, and deviations from secure coding standards.
• Best Practices:
– Follow security guidelines like OWASP, CERT, and secure
coding standards.
– Focus on key areas such as input validation, output encoding,
authentication, and cryptography.

1. Can detect logic flaws and vulnerabilities that automated

tools might miss.
2. Tailored review for business logic, complex algorithms, or
custom implementations.
Time-consuming and labor-intensive.
Requires security expertise.
 Peer Code Review
• Developers review each other's code to identify
potential security issues. It is often part of the
development process (e.g., via GitHub pull
requests).
1. Helps catch issues early in the development process.
2. Promotes knowledge sharing among developers.
– Reviewers might not always focus on security aspects
unless they are trained.
– Potentially limited scope compared to dedicated security
reviews.
 Fuzz Testing (Fuzzing)
• Automated testing that feeds the application with random or
unexpected inputs to discover vulnerabilities such as buffer
overflows, crashes, and unhandled exceptions.
• Tools:
– AFL (American Fuzzy Lop)
– Peach Fuzzer
– Sulley Framework
– libFuzzer
1. Identifies vulnerabilities that arise due to unexpected or
malformed inputs.
2. Highly effective in finding memory-related vulnerabilities.
– Can be resource-intensive.
– Requires a well-defined test environment to analyze the results.
 Penetration Testing (Pen Testing)
• Simulating real-world attacks to identify vulnerabilities.
Security professionals try to exploit the application to uncover
security gaps, such as misconfigurations, insecure APIs, and
logic flaws.
• Types:
– Black-box testing: Tester has no knowledge of the internal
workings of the application.
– White-box testing: Tester has full access to the source code and
architecture.
– Gray-box testing: Tester has partial knowledge of the application.
1. Mimics real-world attacks to reveal serious vulnerabilities.
2. Can test the application’s defense mechanisms.
– Time-consuming and expensive.
– May miss internal flaws unless it’s white-box or gray-box testing.
 Security Unit Testing
• Incorporating security checks into unit tests to verify
that functions, modules, or classes behave securely
under various conditions.
• Tools:
– JUnit (Java)
– pytest (Python)
– NUnit (C#)
1. Allows detection of security issues early, during
development.
2. Integrates security checks into the regular testing process.
– Limited in scope since it focuses on specific
functions/modules, not the whole system.
 Interactive Application Security Testing (IAST)

• A combination of SAST and DAST, IAST tools monitor

an application while it is running to identify
vulnerabilities in real-time by analyzing both code
and runtime behavior.
• Tools:
– Contrast Security
– Seeker by Synopsys
1. Provides more accurate results than SAST or DAST
alone.
2. Detects security issues that occur during runtime.
– May be resource-heavy and could impact the
application’s performance.
 Software Composition Analysis (SCA)
• Scans the application’s dependencies and third-party
libraries to identify known vulnerabilities in open-
source components.
• Tools:
– Snyk
– WhiteSource
– Dependency-Check (OWASP)
– Black Duck
1. Detects known vulnerabilities in third-party code and
libraries.
2. Keeps track of license issues in open-source components.
– Limited to known vulnerabilities (won’t detect zero-day
issues).
– Does not detect vulnerabilities in custom code.
 Security Regression Testing
• Ensuring that previously fixed security
vulnerabilities do not reappear after code changes.
This can be automated with regression test suites.
• Tools: Same tools as unit and functional testing,
often extended with security-specific tests.
1. Ensures new changes don't reintroduce old
vulnerabilities.
2. Can be automated in CI/CD pipelines.
– Requires careful maintenance of the test suite.
 Summary
Method Type Advantages Disadvantages

Static Code Analysis (SAST) Pre-execution Catches vulnerabilities early Can produce false positives
Dynamic Code Analysis Detects runtime
Runtime Limited to running code
(DAST) vulnerabilities

Time-consuming, requires
Manual Code Review Pre-execution Detects logic flaws
expertise

Promotes team knowledge May miss security-specific

Peer Code Review Pre-execution
sharing flaws

Finds buffer overflows and

Fuzz Testing (Fuzzing) Runtime Resource-intensive
crashes

Expensive and time-

Penetration Testing Runtime Simulates real-world attacks
consuming
Integrates with standard
Security Unit Testing Pre-execution Limited to small code units
testing

Interactive App Security Combines benefits of SAST

Mixed Can impact performance
Testing (IAST) and DAST

Software Composition Detects vulnerabilities in Only finds known

Pre-execution
Analysis libraries vulnerabilities

Prevents reintroduction of
Security Regression Testing Pre-execution Needs careful maintenance
bugs
 Static Code Analysis
• static code analysis as the process of examining
source code before it’s run to detect vulnerabilities,
bugs, and compliance issues.
• early detection and as part of a secure SDLC,
allowing developers to fix issues without the
overhead of runtime debugging.
 SAST (Static Application Security
Testing)
• Subset of static analysis focused on detecting
security vulnerabilities, such as SQL injection, cross-
site scripting (XSS), buffer overflows, etc.
 Common Vulnerabilities Detected by
SAST with Coding Examples
• Lets see come coding examples
 Example 1: SQL Injection
• Vulnerability: When an application dynamically
builds SQL queries with user inputs, attackers may
inject malicious SQL code.
import sqlite3
def get_user_data(user_id):
conn = sqlite3.connect("database.db")
cursor = conn.cursor()
query = "SELECT * FROM users WHERE id = " + user_id
cursor.execute(query)
return cursor.fetchall()
If an attacker enters 1 OR 1=1, the query becomes:
SELECT * FROM users WHERE id = 1 OR 1=1
 Fix
def get_user_data(user_id):
conn = sqlite3.connect("database.db")
cursor = conn.cursor()
query = "SELECT * FROM users WHERE id = ?"
cursor.execute(query, (user_id,))
return cursor.fetchall()
Fix explanation
 Example 2: Command Injection
Vulnerability: Command injection occurs when
applications run system commands using user input,
allowing attackers to execute arbitrary commands.
import os

def list_files(directory):
os.system("ls " + directory)
 Fix
import subprocess

def list_files(directory):
subprocess.run(["ls", directory], check=True)
Fix explanation
 Example 3: Path Traversal
Vulnerability: Path traversal exploits improper file
access, allowing attackers to read sensitive files by
navigating the filesystem.

def read_file(filename):
with open("/home/user/data/" + filename, "r") as
file:
return file.read()
 Fix
import os

def read_file(filename):
if ".." in filename:
raise ValueError("Invalid filename")
with open(os.path.join("/home/user/data",
filename), "r") as file:
return file.read()
Fix explanation
 Example 4: Hardcoded Secrets
• Vulnerability: Hardcoded sensitive data (e.g., API
keys, passwords) in source code exposes them if
code is accessed or leaked.

• API_KEY = "my_secret_api_key"
 Fix
import os

API_KEY = os.getenv("API_KEY")
Fix explanation
 Example 5: Insufficient Logging and
Monitoring
Vulnerability: Lack of logging for failed authentication
or suspicious activities reduces visibility into potential
security events.

def login(user, password):

if authenticate(user, password):
return "Login successful"
else:
return "Login failed"
 Fix
import logging

logging.basicConfig(level=logging.INFO)

def login(user, password):

if authenticate(user, password):
logging.info("User %s logged in successfully", user)
return "Login successful"
else:
logging.warning("Failed login attempt for user %s",
user)
return "Login failed"
Fix explanation
 Example 6: Weak Cryptography
Vulnerability: Using outdated or weak cryptographic
algorithms makes data susceptible to decryption
attacks.
from Crypto.Cipher import DES

def encrypt_data(data):
cipher = DES.new(b"12345678", DES.MODE_ECB)
return cipher.encrypt(data)
 Fix
from Crypto.Cipher import AES

def encrypt_data(data):
cipher = AES.new(b"mysecretpassword",
AES.MODE_ECB)
return cipher.encrypt(data)
Fix explanation