Breaking the Kubernetes Kill Chain: Host Path Mount
DevSecCon Boston 2018: Secure by Design by Chris Wysopal
1. BOSTON 10-11 SEPT 2018
Secure by Design
CHRIS WYSOPAL
CTO & CO-FOUNDER
VERACODE
2. BOSTON 10-11 SEPT 2018
In the past…
• Vendors didn’t think about security from
the beginning of the software
development process
• The result was “patch and pray”
• Vendors were reactive and subsequently
customers had to be reactive
• This is not sustainable
3. BOSTON 10-11 SEPT 2018
Then application penetration testing was born…
• Vendors hired experts to test software
right before release
• A mixture of manual and automated
tools were used to generate a list of
security issues
• Vendor decided how much they could
fix and what delay they could tolerate
4. BOSTON 10-11 SEPT 2018
We went from fixing nothing to fixing only the
most critical issues in the most expensive way and
causing the most delay.
5. BOSTON 10-11 SEPT 2018
This doesn’t cut
it anymore
Attackers are everywhere
and their attacks are
more and more
automated
Customers expect more
Losing customer trust
means losing money
6. BOSTON 10-11 SEPT 2018
Principles of Secure by Design
Continuous – security is built-in throughout the
entire software lifecycle
Measurability – ensure the activities performed are
producing the desired result and can be optimized
Transparency – ability to describe your secure
development process and the security mechanisms
you used to regulators and customers
7. BOSTON 10-11 SEPT 2018
Security features are requirements (functional and non-functional) placed into the backlog
Security champions are members of the development team who can determine when new backlog
items need threat modeling or secure code review
Minimize “touchpoints” with security team
Automated security testing is built into the tools developers use: the IDE, CI/CD pipeline, ticketing
systems
Continuous Security
8. BOSTON 10-11 SEPT 2018
Need to be continuous
about dependencies
• Libraries
• Packages
• Containers
How quickly can you
update?
9. BOSTON 10-11 SEPT 2018
Percentage of vulnerabilities not in NVD – 31%
Language CVE Reserved CVE SVE % SVE Low % SVE High
JS 604 47 490 42.94% 44.79%
PHP 522 14 128 19.28% 19.69%
DOTNET 58 0 1 1.69% 1.69%
JAVA 749 60 335 29.28% 30.90%
RUBY 284 43 268 45.04% 48.55%
PYTHON 389 59 228 33.73% 36.95%
GO 90 5 218 69.65% 70.78%
CPP 193 8 12 5.63% 5.85%
OBJECTIVEC 631 14 9 1.38% 1.41%
CSHARP 33 3 0 0.00% 0.00%
3553 253 1689 30.74% 32.22%
% SVE Low assumes reserved CVEs overlap with SVEs
% SVE High assumes reserved CVEs do not overlap with SVEs
10. BOSTON 10-11 SEPT 2018
For Java, Ruby and Python, less than 5% of products that
contain a library with a vulnerability are vulnerable
repos analyzed
% component vulnerabilities that make the
products vulnerable
Ruby 510 3.50%
Java 5232 4.15%
Python 585 0.69%
11. BOSTON 10-11 SEPT 2018
Consistency of tools used across all applications developed
System of record with all results from multiple testing processes
Track activities to correlate with defect and fix rates
Measurability
15. BOSTON 10-11 SEPT 2018
External documentation – security
features, tools, process, components
(SBoM)
Third party validation – verified results
Transparency
16. BOSTON 10-11 SEPT 2018
Thank you!
Chris Wysopal
cwysopal@veracode.com
@weldpond
Hinweis der Redaktion
But I have a secure development process! I’m making secure software! Vendors will say this with a straight face.
Customers are going to ask you about how you develop software
Transparency allows consumers to make informed choices. Describe encryption, key management, etc. Measure fix rate, benchmark, measure benefits of activities such as sandbox, remediation consulting.
Static, dynamic, SCA
Agility is security! Vulnerability management comes to AppSec!
SVE are vulnerabilities gathered directly from open source code repository that are not in the NVD