Reveal the Security Risks in the software Development Lifecycle Meetup 06032024.pptx

Join Us:
https://www.linkedin.com/comp
any/application-security-virtual-
meetups
QR Link:

Why securing the
Software
Development
Lifecycle fails at scale
PRESENTED BY:
Liav Caspi
© Copyright 2024 Legit Security.

Something in AppSec is still missing
Here's some evidence
From the Gartner report, Mitigating Enterprise Software Supply Chain Risk.
From The State of Vulnerability Management in DevSecOps September 2022 (Link)
61%
of U.S. businesses were
directly impacted by a
software supply chain attack
in the 12-month period ending
in April 2023
Software Supply Chain
Attacks persist
12avg
live secrets are submitted per
100 repositories every week,
on average
Secrets are pervasive
and critical threat
66%
of large orgs. have an
average of 100,000
vulnerabilities in their backlog
Vulnerability overload
hinders security

© Copyright 2024 Legit Security. 4
And it’s getting tighter
Creation of NIST SP 800-
218 and SSDF (Secure
software development
framework).
CISA requires a signed
attestation for every gov
seller
Executive order on
securing supply chains
live secrets are submitted
per 100 repositories every
week, on average
SBOM is a
requirement
3rd party governance, open
source licenses, static
analysis, threat modeling,
Most standards double
down on software
security

What changed?
Agile
Continuous Integration, Continuous Delivery
Cloud. Microservices. Containers. SaaS
Complete dependency on 3rd party software
Everything as code
AI and LLMs
Developers make more decisions
Attack surface increased
Millions of vulnerabilities
Application build and composition too complex to
handle manually
Long term trends Outcomes

Attacks keep coming

8
Confidential and
What is a secure software-development-lifecycle?
Building secure software, making secure changes
Securing the software factory
Identifying and fixing security issues effectively

9
Confidential and
The way software is assembled, built and deployed is complex.
Introducing – a simple pipeline
A single code
change:
No
review
required
Server
misconfigure
d
This is a “Highway to the Cloud”
AppSec Control Plane

10
Confidential and
Introducing – the Pipeline
A single code
change:
Vulnerable
Open
Source
SBOM
required

11
Confidential and
1. The way software is assembled, built and deployed is complex.
2. Introducing – the Pipeline
A single code
change:
Deployment
Misconfigurations

12
Confidential and
Introducing – the Pipeline Vulnerable Plugin
accessible to
cloud admin key

13
Confidential and
Introducing – the Pipeline
Base image
contains
vulnerabilities
Artifact storage
has weak
access controls
Unprotected
APIs

14
Confidential and
The REAL picture is much more complex, and has many attack vectors.

Why is it hard to build secure SDLC?
Visibility gap
o Is there a ”checklist”?
o What tools are needed?
What’s critical?
o Constant change
Knowledge gap
o Noise, lot’s of false
positives
o Context missing
o Putting off fires instead of
fixing the root cause
Too many findings
o Build systems are
unprotected
o Secrets. Secrets everywhere
o Bad development hygiene
can have catastrophic
consequences
The tools are insecure
o How is application built?
o Many components and
component classes
o 3rd party links

A deleted secret is an honest mistake.
It won’t come up in code review
It might stay in Git history forever (until
found)…
Example #1 – Secrets in code

Example #1 – Secrets in code docs

Example #2 – GitHub Actions pawned
1. Developer creates a pull request
2. Automated tests are triggered before any human
reviews the code
3. Automated tests contain a flaw that allows the
changes to run custom command in a privileged
pipeline context
4. Attacker can use the context to steal credentials,
make any change to the GitHub org and clean up the
change request
Further read
How many are aware to how to
write a safe pipeline script?
Third party actions may make the
org vulnerable regardless..

Example #3 – Secure your artifacts
30%
of internet facing private
artifact registries expose a
high and above CVE
9%
Expose secrets and internal
technical data

Thank you!
Questions?

THE REAL
APPSEC ISSUES
JOSH GROSSMAN
CTO, BOUNCE SECURITY
March 2024
21

Josh Grossman
■ Over 15 years of IT and Application
Security, IT Risk and development
experience
■ CTO for Bounce Security, value-
driven Application Security support
■ Consulting and training for clients
internationally and locally
■ Contact:
– @JoshCGrossman
– josh@bouncesecurity.com
– https://joshcgrossman.com/
– https://github.com/tghosth
■ OWASP Israel Chapter Board
■ Co-leader of the OWASP ASVS
Project
■ Major Contributor to the OWASP
Top Ten Proactive Controls project
■ Contributor to:
– OWASP Top 10 Risks
– OWASP JuiceShop
22
The Real AppSec Issues
@JoshCGrossman

AppSec in real breaches
@JoshCGrossman 23
Verizon 2023 Data Breach Investigations Report
https://verizon.com/dbir/

@JoshCGrossman 24
---[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 08 of 12

@JoshCGrossman 25
https://owasp.org/Top10/

Who are you?
26
@JoshCGrossman

The real issues
■ Not your standard OWASP top 10
– A different “top 10”
■ Observed from real organizations and people
■ Food for thought
27
@JoshCGrossman

The real issues
■ Not your standard OWASP top 10
– A different “top 10 6” (6 issues is enough!)
■ Observed from real organizations and people
■ Food for thought
28
@JoshCGrossman

1) Security is the developer’s job?
■ Not taught University, boot camps, online
tutorials.
■ Rarely incentivized or measured on this
■ Performance, UX, etc, are at least 2nd class
citizens...
– ...security usually isn’t.
■ Can’t secure from the sidelines
30
@JoshCGrossman

1) Security is the developer’s job?
My advice:
■ Security = a software characteristic
■ Need buy-in from R&D management – “Shift up”*
■ Interactive/interesting training
■ Security champions program
– Starting?
– Sustaining?
31
@JoshCGrossman
* Heard this from Francesco Cipollone
@FrankSEC42

32
@JoshCGrossman

2) What is OWASP?
■ Many developers are not familiar
■ OWASP can bring:
– Comprehensive requirements for security
– Networking and knowledge sharing
– Interactive developer training (members)
33
@JoshCGrossman

2) What is OWASP?
■ Questions:
– Can you name an OWASP project (not the top
10?)
– Have you been to an OWASP
meetup/conference?
34
@JoshCGrossman

2) What is OWASP?
■ Questions:
– Can you name an OWASP project (not the top
10?)
– Have you been to an OWASP
meetup/conference?
– Who has devs who go to OWASP meetups or
conferences? (more important)
35
@JoshCGrossman

■ Encourage R&D to be involved
■ Avoid “reinventing the wheel”
■ Build familiarity and find what works for them
– Tools like ZAP, Dependency-(Track|Check)
– Documents like ASVS, Cheat sheets
– Get involved in the Slack channel
36
@JoshCGrossman
2) What is OWASP?
My advice:

3) Tool fatigue
■ Software security = SAST/DAST/SCA/etc?
37
@JoshCGrossman

3) Tool fatigue
■ Software security ≠ SAST/DAST/SCA/etc
■ Problems
– Noisy, poorly configured tools
– Poorly aligned metrics
– Massive finding backlogs
38
@JoshCGrossman

3) Tool fatigue
■ Software security ≠ SAST/DAST/SCA/etc
■ Problems
– Noisy, poorly configured tools
– Poorly aligned metrics
– Massive finding backlogs
■ Software security = Frustration with security tools
39
@JoshCGrossman

■ Cannot really be summarized in 3 bullets…
– Tools should support a goal
– Get clear management buy-in
– Gradual approach to findings (expectations)
■ Get the benefit by treating as a process
40
@JoshCGrossman
3) Tool Fatigue
My advice:

Penetration testing is like….
41
@JoshCGrossman

4) Pen testing is low value
■ Hard to judge quality of tester
■ Why are there:
– no findings?
– too many findings!
■ Findings not aimed at developers
■ Highlighted by Haroon Meer at 44CON
2012: “Penetration Testing Considered
Harmful” (Market for Lemons)
42
@JoshCGrossman

4) Pen testing is low value
My advice:
■ Get details of the tester's experience
■ See an example report
■ Testing based on a standard (e.g. ASVS)
■ Bug Bounty company better for high-risk issues?
– Specifically, as a penetration test!
https://appsecg.host/pentest
43
@JoshCGrossman

5) Integrating security early
■ "Shifting left" (should be "spread left")
■ Hard to create consistent process for:
– Security requirements
– Design security
– Threat modelling
■ Starting is easyish, continuing is hard
44
@JoshCGrossman

5) Integrating security early
My advice:
■ Consistent set of requirements
■ Customize based on feature characteristics
■ Tailored, developer led processes
■ Lightweight threat modelling
45
@JoshCGrossman

6) Security as project management
■ How much time spent on tasks requiring security
knowledge?
– Chasing metrics?
– Monitoring progress?
– Building project plans?
46
@JoshCGrossman

6) Security as project management
My advice:
■ R&D take responsibility for metrics
■ Security project manager / operations specialist
■ Make it to management clear where security
expert time is going
■ Security can focus on guiding and improving
47
@JoshCGrossman

Summary of issues
1. Security is the developer’s job?
2. What is OWASP?
3. Tool fatigue
4. Pen testing is low value
5. Integrating security early
6. Security as project management
48
@JoshCGrossman

Want to hear more?
49
@JoshCGrossman
Building a High-Value AppSec Scanning
Programme
https://appsecg.host/lisreg
Accelerated AppSec – Hacking your Product Security
Programme for Velocity and Value (Virtual)
https://appsecg.host/bhreg

Key takeaways
50
@JoshCGrossman

Key takeaways
■ Strategic and collaborative approach
■ Software security is software quality
■ Meet developers where they are
■ Tools should support a wider process
51
@JoshCGrossman

THANKS FOR LISTENING!
Josh Grossman
Bounce Security
josh@bouncesecurity.com
https://JoshCGrossman.com
@JoshCGrossman
52
• Strategic and collaborative approach
• Software security is software quality
• Meet developers where they are
• Tools should support a wider process
Questions?

“ When AppSec Met IR “
Vitaly Davidoff
CISSP, CSSLP

Agenda
54
1. What is IR?
2. Why appsec team?
3. End 2 End Process (Roles and Responsibilities)
4. PPT (Processes, People, Technologies)
5. Example
6. Summary

Incident Response Overview
55
Incident response is an organized approach to addressing
and managing the aftermath of a security breach or
cyberattack. The goal of an Incident Response plan or
procedure is to handle the situation in a way that limits
damage and reduces recovery time and costs.

Critical CVE In Production - An Incident?
57

Why Application Security Team?
58
1. Software Security - special knowledge
2. What if we are not affected?
3. Research for attack path (scan for vulnerabilities)
4. Safe money, time and effort
5. Response to Customers (Justification)
6. Remediation options and fix verification

Where AppSec team will help
59
Response
Provide technical advisory
justification for customers. Do
a research for attack
breadcrumbs inside logs,
publish CVE. Discuss
holistic solution for specific
issues.
Research
Understand vulnerability
details, create attack
simulation. Explain attack
vector to appropriate
stakeholders. Communicate
with external
researchers/customers to
obtain more details.Work
with R&D teams to verify
issue applicability..
Recovery
Provide technical
suggestions and guidelines
for remediation. Work with
R&D and DevOps/Operations
teams to provide workarounds
(temporary mitigations) if
need. Verify mitigation code
(code review, test security fix)

Documents and Communications
60

Security Tools
62
https://jfrog.com/help/r/jfrog-security-documentation/vulnerability-contextual-analysis

Conclusion
64
1. Critical zero days CVE’s - should be part of IR
2. AppSec team can safe you money and effort
3. Security champions - your best friends
4. Use security tools if possible
5. Response to Customers - AppSec team responsibility to
provide a justification

The ASPM Way
A new approach
PRESENTED BY:
Liav Caspi

What is ASPM?
A new class of solutions and technology to help managing appsec, efficiently and at scale
It is based on the following principles
Complete visibility Secure the environment Contextual prioritization Collaboration & automation

Visibility
Repositories, tech stack
Developers, permissions
Tools, systems, plugins
3rd party / open source dependencies
Artifacts
Secret management
LLM / AI BoM
More…

What do we get from extreme visibility?
Respond to an event – vulnerable Jenkins plugin, Log4Shell
Find critically insecure configurations
Plan what we need?

Risk management
Stuff we fix
Problems we
create
RISK

Fix More Risk No more new
You must do it simultaneously
DevSecOps guardrails
Secure infrastructure
Developer awareness
Automated remediation
Find smarter ways to prioritize.
Root causes
Bulk operations
Exploitability / reachability

How ASPM helps #1 – contextual prioritization

How ASPM helps #2 – DevSecOps Guardrails
o A guardrail catches vulnerabilities
before they reach runtime
o It doesn’t have to be blocking
o Reduces load from security teams

How ASPM helps #3 – Git configuration security
Review required
MFA enforced for all developers
Only verified actions
Workflow can’t approve
themselves
And dozens more…

Getting started
Consolidate an inventory and map the attack surface
ASPM tools are available to generate gap reports
Configuration scanners – you can start for free ( see Legitify)
Start small- introduce security scanners. Don’t forget data

See how we help enterprises
optimize their AppSec:
legitsecurity.com

Thank You!
Questions?
To be continued…
https://www.linkedin.com/company/application-security-virtual-meetups

Reveal the Security Risks in the software Development Lifecycle Meetup 06032024.pptx

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Reveal the Security Risks in the software Development Lifecycle Meetup 06032024.pptx

Ähnlich wie Reveal the Security Risks in the software Development Lifecycle Meetup 06032024.pptx (20)

Mehr von lior mazor

Mehr von lior mazor (19)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Reveal the Security Risks in the software Development Lifecycle Meetup 06032024.pptx