The document outlines the S-SDLC (Secure Software Development Life Cycle) frameworks, including waterfall, agile, and CI/CD approaches, with a focus on application security and risk management practices. It emphasizes the importance of addressing security vulnerabilities early in the development process to reduce remediation costs and increase effectiveness. Key statistics highlight the significant percentage of risks not covered by existing tools and the necessity for a structured approach to both secure coding and testing.

1. S-SDLC FRAMEWORK
UNKNOWN
Rishi Kant

2. AGENDA
About me
Pre requirements & Business expectation
General DAST Process
Effectiveness of AppSec Program
AppSec quality improvement approach
S-SDLC | Type 1 | Waterfall
S-SDLC | Type 2 | Agile
S-SDLC | Type 3 | CI/CD
Comparison of all 2 approach

3. ABOUT ME!
I am Rishi Kant
I am a Security professional with 11+ years of corporate experience in the field of Cyber Security,
Information Security, Digital Forensics, GRC, IT Administration, Secure Software Development,
Training, and company operations. I worked in various industry verticals such as Utilities, IT/ITES, E-
Commerce, Government, BFSI and law-enforcement agencies.
https://www.linkedin.com/in/hrishikant

4. PRE-REQUIREMENTS
Knowledge of Waterfall SDLC
Knowledge of Agile SDLC
Cyber Security approaches
Security testing Behaviors
Vulnerability Analysis
BUSINESS EXPECTATIONS
PROCESSES OPTIMIZATION
FOR TIME REDUCTION,
INCREASE BUSINESS SPEED,
REDUCE HUMAN EFFORTS
EFFECTIVE RISK
MANAGEMENT
FRAMEWORK
COST REDUCTIVE PROCESS
AND LESS CONTROL
IMPLEMENTATION COST

5. GENERAL PROCESS IN TYPICAL ORGANIZATION
TIMELINES
2/3 DAYS 10/15 DAYS 1/2 DAYS
1 DAY BUT
CYCLIC
Understanding
the scope
Perform tests as
per the scope
Report generation and
clearing the doubts
Cyclic phase for re check
the issues

6. RISK
SOFTWARE PROJECT PROGRESS
IDENTIFY
CONTROL
IMPLEMEN
T CONTROL
VALIDATE
CONTROL
We have jumped straight to
validation without identifying the
root cause and implementing the
appropriate controls to reduce
application security risk.
TRACKING THE EFFECTIVENESS OF AN APPLICATION SECURITY PROGRAM

7. 46% OF APPLICATION-LEVEL RISKS ARE NOT COVERED BY SAST & DAST TOOLS
Source Code SAST & DAST
Remediation
30% of total risks found & fixed
average time to remediation = 316 days*
54% of risks found*
46% of risks are not
found
70% of risks unaddressed
24% of risks found, not fixed
54% remediation rate*
*Adapted from:
National Institute of Standards and Technology. “Report on the Static Analysis Tool Exposition IV”.
Gartner for Technical Professionals. “Application Security Think Big and Start with What Matters”.
Veracode. “State of Software Security”, 2016.
WhiteHat Security. “Web Applications Security Statistics Report”.

8. Source Code SAST & DAST
Remediation
30% of total risks found & fixed
average time to remediation = 316 days*
54% of risks found*
46%of
risks are
not found
70% of risks unaddressed
24% of risks found, not fixed
54% remediation rate*
*Adapted from:
National Institute of Standards and Technology. “Report on the Static Analysis Tool Exposition IV”.
Gartner for Technical Professionals. “Application Security Think Big and Start with What Matters”.
Veracode. “State of Software Security”, 2016.
WhiteHat Security. “Web Applications Security Statistics Report”.
46% OF APPLICATION-LEVEL RISKS ARE NOT COVERED BY SAST & DAST TOOLS

9. Source: Applied Software Measurement, Capers Jones, 1996
• Cost of remediation is always lesser in
coding phases irrespective to number of
bugs found.
• Impact on services, risk delta is always
increases as the SDLC phases increases.
• Increase in effectiveness of controls
help to decrease the number of bugs
found and remediation costs.
• Decrease the impact on reputation,
brand, business, reliability.
STATISTICS ANALYSIS OF REMEDIATION COST PER STAGES
“The cost of removing an application
security vulnerability during the design
phase ranges from 30-60 times less than
if removed during production.”
NIST, IBM, and Gartner Group

10. APPLICATION SEC. QUALITY IMPROVEMENT APPROACH
Definition Pre-Design Design Development Deployment
CheckPoint 1 CheckPoint 2 CheckPoint 3 CheckPoint 4 CheckPoint 5
Concepts / Priority Selection of Controls Preliminary Design
AGREEMENT
Design & Review Approve Build
• High Level Security
Risk Analysis
• Risk Base Security
Plan
• Selection of
Controls
• Selection of Service,
protocols
• Security Design
Review
• Third part assets
control selection
• Secure Code review
• Data flow review
• Vulnerability
Assessment
• Penetration testing
• Third party
assessment

11. WATERFALL APPROACH FOR S-SDLC
Business
Requirements
Application Portfolio Analysis | User Risk Analysis | Security Requirements Analysis
Pre-Design
Secure Design Analysis | Risk Assessment | Architecture Review Plan | Threat Modeling
Design
External Security Review | Design Risk Analysis | Architecture Risk Analysis
Post-Design
Dev. Test Plan | Review of Data Flow charts | Communication channels/Services
Development
Secure Code Guidelines | Static Code Analysis | Developer Training | Coding Standards Development
Testing
Security Metrics Development | Test Reviews | Dynamic Code Analysis | DAST
Deployment
Pre-Implementation Risk Management
Maintenance

12. AGILE APPROACH FOR S-SDLC
Initial
Phase
Application Portfolio Analysis | User Risk Analysis | Required Training
Creation User
Stories
Secure Design Analysis | Risk Assessment | Architecture Review Plan | Security Requirement Analysis
Creation
Product
Backlogs
Design Risk Analysis | Architecture Risk Analysis | Threat Modelling
Creation
Sprint
Backlogs
Security Metrics Development | Communication channels/Services | Secure Code Guidelines | Coding Standards
Development
Sprint
Lifecycle
Static Code Analysis | Developer Training | Dynamic Code Analysis | DAST
Finishing
Sprint
Test Reviews | Pre-Implementation Risk Management
Sprint
Retrospective
Feedbacks | Security Improvement Plan
Maintenance

13. GENERAL AGILE SDLC
Client
Product
Owner
Sprint Plan
Meeting
DevOps Team
User Stories
Sprint Backlog
Sprint Life Cycle
Product Backlog
Finish of Sprint
Sprint Review
Sprint Retrospective
Feedbacks
• Product owner accept the inputs from the Client to conclude the user stories for product backlog.
• Every product backlog further divided into sprint backlog as per the group of same type of functionalities.
• Every Sprint backlog have the cycle of Coding and testing aligned with daily follow-up scrum meeting with scrum master, product owner, developers.
• Scrum meeting is on daily basis for better analysis the growth of the project.
• On the finish of Sprint, we need to review followed by Sprint retrospective for feedback to product owner likely for gaps evaluation.

14. CI/CD APPROACH S-SDLC
Continuous Delivery
Continuous Integration
PRO UAT QA DEV
Version Control
Developer 1 Developer 1Scrum
Master
Service
Desk
1
2
3 4
5
6
7
Check 4 Changes
Fetch Changes
Notify issues
Send Backlog

15. WATERFALL | AGILE | CI/CD IN S-SDLC
• Waterfall SDLC easy to alignment with Secure SDLC irrespective to Agile & CI/CD methodologies.
• Waterfall model follow the consecutive process irrespective to Agile & CI/CD methodologies.
• Implementation of Security in waterfall is easier then Agile & CICD but we can use some enhanced
criteria for better & secure agile/CI/CD SDLCs
Business
Require
ments
Application Portfolio Analysis | User Risk Analysis | Security Requirements Analysis
Pre-
Design
Secure Design Analysis | Risk Assessment | Architecture Review Plan | Threat
Modeling
Design
External Security Review | Design Risk Analysis | Architecture Risk Analysis
Post-
Design
Dev. Test Plan | Review of Data Flow charts | Communication channels/Services
Develop
ment
Secure Code Guidelines | Static Code Analysis | Developer Training | Coding
Standards Development
Testing
Security Metrics Development | Test Reviews | Dynamic Code Analysis | DAST
Deploy
ment
Pre-Implementation Risk Management
Secure SDLC in Waterfall Secure SDLC in Agile Secure SDLC in CI/CD
* Perfectly aligned with security blocks * Hard to fit as per the security blocks
Continuous
Delivery
Continuous
Integration
PRO UAT QA DEV
Version
Control
Deve
lope
r 1
Deve
lope
r 1
S
c
r
u
m
M
a
s
t
e
r
S
e
r
v
i
c
e
D
e
s
k
1
2
3 4
5
6
7
Check 4 Changes
Fetch Changes
Notify issues
Send Backlog
* Hard to fit as per the security blocks

16. THANK YOU!
Any questions?
You can also find me at rishi-kant@live.in for any further questions