Source Code Analysis

Question 1

What can we do to be sure that code is trustworthy ?

Answer 1

Evaluate binary

• Review source code, compile yourself
• Evaluate compiler
• Review compiler source code? +compiler’s compiler?
• Review compiler machine code?
• Evaluate operating system
• Evaluate hardware, firmware

Evaluate persons, processes

Question 2

what are risks to outsourcing and offshore development ?

Answer 2

Untrustworthy staff
- Contract workers, contractors, sub-contracting
- Insider threat, traceability of code origin/modification
Untrustworthy suppliers
- Products: Libraries, components
- Services: Deployment, operation

Question 3

What trust models exist for ICT supply chain ?

Answer 3

“Blind trust”, “Trust by directive”, “Liability”
-> Sufficient to evaluate 1st supplier

“Reputation”, “Strong interest”
-> Evaluate 1st supplier + 3rd party components

“Proven in use”
->All relevant components known and evaluated?

Higher risk

• “Weak interest”
• > Supplier without active interest
• “Idealism”
• > Supplier might be harmed by others

Question 4

What are factors that need to be considerd for software inspections ?

Answer 4

Effectiveness: how much reduction?

Efficiency: at what cost?

• Manual reviews: Skilled labor is scarce
• Automation (but manual follow-up)

Risk-based analysis/testing
- Reduce scope

Question 5

what is the goal for software inspections ?

Answer 5

Reduce vulnerabilities in code

Question 6

what are advantages of software inspections ?

Answer 6

Ensure that more than one person
has seen every piece of code

Prospect of someone else reviewing
your code raises quality

Force developers to document decisions

Train junior developers to get familiar with code base

Question 7

What are methods used to find vulnerabilities ?

Answer 7

Black box
- Same situation as attackers

White box
- Insider knowledge, e.g., review of source code

Grey box

Question 8

How could an example process of a code review look ?

Answer 8

1. Define scope
2. Collect information
3. Review: design, code; test
4. Document findings
5. Analyse findings: severity, remediation effort
6. (Support remediation)

Question 9

Which parameters define the scope of a code review ?

Answer 9

Goal of review
– Ease of detection, severity, code coverage, depth
– Business context
– Compliance with regulations

Type of access
– Source
– Binary, binary+debug info
– Black box access to interfaces

Question 10

What tools can aid in the definiton of the scope ?

Answer 10

Coverage
- Execute test cases, measure coverage, i.e. which parts of
code affected
- Inspect affected code (assumption: what is not tested is less
relevant code)

Call graphs

• Identify modules used by many
• E.g. CScout

Hot spots
- Issue trackers: modules mentioned often (past experience)
- Version control logs
- Code modified often
- Code modified often because of bug fixes
- Defect prediction (type of change, dev. experience,
affected LOC, affected #files)
- Code metrics: complexity, #dependencies
- Code visualisation
- E.g. CodeCity, Gource

Question 11

Where can we collect infos while doing a code review ?

Answer 11

System documentation

Developer documentation
– Might not exist or might not be current
– Version control log is also documentation
Interviews: be polite

Documentation of standards that are used

Source code: get overview, get feeling

Deployed system: get overview, run scans

Question 12

What are the steps while doing the actual review ?

Answer 12

Plan: Decide what to look for and how
- High level (design) vs low level (implementation)
- Assets, entry points, trust boundaries, relationships
Review: Perform the review
- Vary: people, perspective
- Take notes, annotate source code
- Stay focused, do not get lost in details
Reflect: What worked well, what did not?
- Relate to review goals

Question 13

What are common review strategies ?

Answer 13

Code comprehension
– Analyse source code, gain understanding
– Trace input, analyse module/algorithm/class

Candidate points
– List potential issues, then examine source code
– Tools often used to create list

Design generalisation
– Recover design from source code
– Identify missing trust boundaries

Question 14

What tools are used during the review stage ?

Answer 14

Code browsers
– Navigation in code, often integrated in IDE
– Cross-referencing variable/function definition/use
– Formatting/pretty-printing, make code easier to read,
e.g. Artistic Style (http://astyle.sourceforge.net)
– Call graphs, functional dependencies

Version control logs

Issue trackers (linked to version control)

Question 15

What should be documented after a code review ?

Answer 15

Method used

Code coverage

Findings
– Threat, description, impact, location
– Proposed remediation (steps, effort)

Question 16

What comes after a code review ?

Answer 16

Support remediation:
- Not part of review, but consequence of review
- Knowledge gained in discovery useful for fixing
- To fix or not to fix
-Estimate effort
- Business context
- Alternatives: change configuration,
reduce functionality, change environment
- Review fix

Question 17

What can Type Systems do in terms of Security ?

Answer 17

Support security by
– imposing discipline/restrictions on developer
– enforcing abstractions on developer

Question 18

What is Memory safety ?

Answer 18

Programming language ensures that only allocated (and

initialised) memory can be referenced

Question 19

What is Type safety ?

Answer 19

– Types annotate program elements to assert invariant
properties (e.g. integer, array, string)
– Type checking verifies the assertions

Question 20

What is Static code analysis and what are advantages ?

Answer 20

Detection of errors in a program without executing it
- No overhead in execution
- Often automated
- Focus on implementation vulnerabilities
- Beneficial for software quality in general
- Avoiding vulnerabilities is one aspect
- Often detects more (and different) errors
than manual review
- Examine unusual execution paths

Question 21

What are disadvantages of static analysis ?

Answer 21

False positives
– Static analysis tool reports non-error
– Low rate of false positives important,
critical for acceptance
– Big issue with existing code

False negatives
– Tool does not report error
– Static analysis does not cover all classes of vulnerabilities,
even if you buy all the combined tools on the market

Question 22

What are issues that can be cought with an analysis at compile- time ?

Answer 22

Analysis at compile-time
- Syntactic checks (often caught by compiler)
- Type checking (often done by compiler)
- Program semantics
- Unused variables, unreachable code, missing
initialisation
- Dataflow analysis, control flow analysis, abstract
interpretation, program verification, model checking

Question 23

What are classes of programm error ?

Answer 23

Data
– Are all variables initialized before use?
– Have all constants been named?
– Array lower bounds: 0, 1, k?
– Array upper bounds: size? size-1?

Control flow
– Correct conditions for conditional statements?
– Termination of loops?
– Correct bracketing?
– All cases accounted for in switch statements?

Question 24

What are analitcal approaches used in static code analysis ?

Answer 24

Syntactical analysis (find strings in source code)

Lexical analysis
– Match sequence of tokens against pattern

Data-flow analysis
– Determine possible values for variables

Abstract interpretation
– Model execution on (simpler)
abstract machine
– Define abstract security requirements
in advance, e.g., access to resources