While engineers are increasingly aware of security requirements, in many organizations security remains the responsibility of “those security people” and is not tightly integrated into the development cycle. Productivity and feature goals can result in engineers focusing on deployment rather than on fixing non-critical security issues or on building security into a product, resulting in an increase of security technical debt. Attackers eagerly exploit the vulnerabilities lying in the security technical debt pile. Organizations can benefit from risk-based practices for shrinking this debt. This talk will present two research projects in which risk is being used to prioritize security mitigations. The first project is focused on reducing secrets and credentials that have been checked into a code base. The second project relates to the prioritization of patching the continuous onslaught of vulnerable components and libraries that comprise a product.
1. Risk-based Security
Technical Debt Reduction:
When everything’s
important, nothing gets done
Laurie Williams
laurie_williams@ncsu.edu
Real People – Real Projects – Real Impact 1
3. Think Like a Thief
• Put yourself in the mind of a thief …
Plan a robbery!
• Choose a scenario that would have a high chance of success,
lay out the details …
• How long do you think it would take to plan & execute the
theft? How much would you hope to gain in terms of value ($
or otherwise)? What would be the effect of the theft on the
victim?
4 minutes … be
ready to share
8. Computing Security Risk Exposure
Traditional Risk
Exposure
probability of
occurrence
X impact of loss
NIST Security Risk
Exposure
likelihood of threat-
source exercising
vulnerability
X impact of adverse event on
organization
Proposed Security
Risk Exposure
ease of attack X value of asset
12. With the very best of intentions …
when everything’s important, nothing gets
done.
Vulnerable components Checked in Secrets
13. State of Vulnerable Components
13
* Snyk: State of Open Source Dependencies 2019
Vulnerable components Checked in Secrets
14. Value Ease
Increases over timeSeverity (e.g. CVSS)
Depth in dependency tree?
Popularity of package
Vulnerable components Checked in Secrets
15. Developer actions
•Git Notified*:
• 262K GitHub projects; Jan 2017 – Dec 2018
• 13% of vulnerable components fixed after GitHub
notification
• Pretty lame … but it can get worse ..
• 9% of vulnerable components fixed after CVE notification
but before GitHub notification
• Tools are needed!
• 40% fixed if notified at time of vulnerability-introducing
commit
• Shift left!
• No difference in fix rate when considering severity
• What’s up with that?
15
*Git Notified: Characterizing Vulnerable Dependency Alerts on GitHub
???
Vulnerable components Checked in Secrets
16. 16
Don’t actually use the
vulnerable part of the
dependency
Don’t actually use the
dependency
CVE / NVD
Dependency is in non-
production code.
Advisories
13% are fixed –
from the white or
grey?
Some obscure package
it’s unlikely an attacker
write an exploit for
Vulnerable components Checked in Secrets
17. Tools help … and are beginning to focus on risk
and more….
Vulnerable components Checked in Secrets
18. With the very best of intentions …
when everything’s important, nothing gets
done.
Vulnerable components Checked in secrets
19. Value Ease
Varies wildly!
All code matters
Varies wildly!
Decreases over time
p(password/key works)
p(asset is still there)
Vulnerable components Checked in secrets
20. Infrastructure as Code Security Smells
Admin by default
Empty password
Hard-coded secret
Invalid IP address binding
Suspicious comment
Use of HTTP without TLS
Use of weak cryptography algorithm
$power_username=‘admin’
password=>‘’
$power_password=‘admin’
$bind_host=‘0.0.0.0’
#FIXME(bogdando) remove these hacks
after switched to systemd service.units
$quantum_auth_url = ‘http://127.0.0.1:35357/v2.0’
password => ht_md5($power_password)
20
* Gang of Eight: A Defect Taxonomy for Infrastructure as CodeScripts
Vulnerable components Checked in secrets
22. GitHub Analysis
• “billions of files”
• Private key files
• 11 high-impact platforms with distinctive API key formats
• Secret leakage in 100,000 repositories … thousands of new, unique
secrets are leaked every day.
• Committing cryptographic key files and API keys embedded directly in
code are the main causes of leakage.
22
How Bad Can It Git? Characterizing Secret Leakage in Public GitHub Repositories
Vulnerable components Checked in secrets
24. Tools can help
24
STATICALLY
IDENTIFY
SECRETS
MACHINE
LEARNING TO
REDUCE FALSE
POSITIVES
NOTIFY UPON
CHECK IN
(SHIFT LEFT)
BUT, ALL
SECRETS ARE
”EQUAL” …
Tools can help
25
STATICALLY
IDENTIFY
SECRETS
MACHINE
LEARNING TO
REDUCE FALSE
POSITIVES
NOTIFY UPON
CHECK IN
(SHIFT LEFT)
BUT, ALL
SECRETS ARE
”EQUAL” …
Vulnerable components Checked in secrets
30. 30
Vulnerabilities in
indirect dependencies
account for 78% of
overall vulnerabilities.
Risk of a
vulnerability in a
dependency of a
dependency of a
dependency of a
dependency?
(Unknown)
* Snyk: State of Open Source Dependencies 2019
Vulnerable components Checked in Secrets
