Please enable JavaScript.
Coggle requires JavaScript to display documents.
S2L3 - Code Review and Security Testing (Review Types and Process (Online…
S2L3 - Code Review and Security Testing
Code Review
Developers other than one who wrote it, review code for defects.
May be approved to production or sent back to original dev for rework of issues found
Defect
Bug, Fault, Problem, Issue
Requirement not satisfied
S/W incomplete, incorrect, missing
Review Types and Process
Online Process
Monitor Quality level during development process
Offline Process
It is performed after completion of software or milestone
Semi Inspection Process
Performed when one of more components of software completed
Walkthrough Process
Used to improve quality of SW and improve learning curve of junior developer. Sit with code writer to find defects
Formal Inspection Process
Schedules meetings, prepared participants, defined agenda, results into a documented output
Informal Inspection
Meetings over coffee, regular team meetings
Fagan Inspection
Fagan Inspection
Inspection of any document that is deemed complete and ready for use
Steps
Plan Inspection by Moderator
Overview, communicate, educate and circulate info about the software
Preparation, all participants perform individually review materials to detect defects
Inspection, paraphrases design, identify and note problems without solving
Rework, all errors/problems addresses
Follow-up, moderator ensures all errors have been corrected. If more than 5% rework, re-inspected by same team
Planning -> Overview -> Preparation -> Inspection -> Rework -> Follow Up
Usefulness
Involved early in documentation and development and throughout SDLC
Well documented track record in reduction in rework costs and defects
Plays major role in training junior staff and transferring expertise
Why rarely used?
Professional Ignorance
Organisational Ignorance
Difficult
Disappointment & frustration
Benefits are intangible
Security Testing
Static Testing
Examination & evaluation of sw security and related documentation w/o executing software
Use automated tools to detect sw common flaws
Dynamic Testing
Involved interaction & evaluation of sw security while it runs.
Dynamic testing on production environment should be careful to avoid unintended interruption of service.
use of SYNTHETIC TRANSACTIONS to verify system performance. Scripted transactions with known results
Fuzz Testing
Automated sw testing technique that involves providing invalid, unexpected or random data as inputs to limits and detect flaws.
Interface Testing
Modules developed seperately. Handoffs between these use well defined interfaces so that team work independenty
Assess performance of module against interface specs to ensure they work properly when all dev efforts are complete
Types of Interfaces
API (App Programming Interface)
offer standardised way for modules to interact and may be exposed outside through web services.
Test to ensure enforce security requirements.
UI (User Interface)
such as GUI and CLI provide interaction
Interface tests should include reviews of UI to verify function properly
Physical Interfaces
Exist in some app that manipulate machinery, logic controllers, objects physical world
Pay attention to consequences if failure
Misuse Case Testing
Attempt to exploit known vulnerability use cases with manual and/or automated attack techniques
Test Coverage Analysis
Unfortunately impossible to completely test any piece of software. Too many ways app may fail.
.
Test Coverage Analysis estimates degree of testing conducted against new sw.
Number of test done/total number of use case
.
Highly subjective calculation. Accurately needs identifying all possible use cases which is difficult