Knowing where vulnerabilities exist is only helpful when you can actually treat them. Unfortunately, a vast majority can only be corrected within an organization’s custom code.
Some organizations write custom patches, but contend with open source software package updates that break those custom patches, so there are significant forward compatibility challenges.
There’s no point in playing security whack-a-mole.
What dev, security & infrastructure teams need to know to improve test cycles:
👉 What software components are running in a workload
👉 What components actually gets used
👉 What components can be eliminated
👉 What vulnerabilities exist after unused components are eliminated
It’s more important to understand how a workload functions than it is to understand where vulnerabilities exist.
Get the full scoop in on how to Stop Chasing Vulnerabilities & Start Improving Test Cycles: loom.ly/OakpAAE
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Severity is how much damage a hacker can inflict exploiting a product using that vulnerability. It doesn’t mean this is the most critical risk facing your system, but many developers mistakenly think it is.
1/ Severity & other information related to a known issue are catalogued in a Common Vulnerabilities & Exposures (CVE) database.
2/ The rubric for scoring severity is the Common Vulnerability Scoring System (CVSS), an open framework for communicating the characteristics & severity of software vulnerabilities.
Several factors are classified into three categories: base, temporal & environmental.