We recently held a webinar discussing software risks and organizational impacts that arise from security flaws in code (you can watch the recording here). Hacking, data breaches, and functional failures are just the tip of the iceberg when it comes to security vulnerabilities and it’s telling that the average application out there has 22.4 security risks.
Here are three of the five methods we recommended to reduce your security risks (along with the times in the recording that you can fast forward to):
• Never trust inputs (5:45)
• Check your code – we walked through an example of a buffer overflow (12:27)
• Use threat modelling (33:48)
We also ran several polls throughout the webinar to get a better idea of our audience. These two questions helped us understand the security environment that our organizations deal with:
Has your organization been affected by a security threat in the past year?
Yes – 57%
No – 43%
How many people on your team actively test for security flaws in code?
None – 36%
Between 1 and 5 – 60%
More than 5 – 4%
These results are a mixed bag: on the one hand, more teams include security testing into their process than not (a good thing!) but on the other, plenty of the same teams have been affected by a security threat. This speaks to the prevalence of threats out there and teams recognizing that something has to be done.
Another interesting result was the development phase in which most security vulnerabilities were found:
At what point in the lifecycle does your team find the most security vulnerabilities?
Design – 12%
Code – 17%
Test – 34%
Maintenance – 37%
This is a statistic we’d like to change – development teams should be finding flaws earlier in the lifecycle, making them faster and more cost effective to fix (imagine realizing that a bounds check is incorrect seconds after you’ve written it … now imagine making that correction after the code’s been built and used somewhere else). By using static analysis that embeds results into your IDE, we can shift defect discovery into the coding phase, preventing flaws before they become too expensive to fix.
This doesn’t just apply to new code that you’re creating, it also applies to code that you’re bringing in from the outside, such as open source software (OSS):
What percentage of your code is open source?
Between 1% and 25% – 54%
Between 26% and 50% – 28%
Between 51% and 75% – 7%
Between 76% and 100% – 11%
Static analysis can help here or, if you’re unsure about where OSS exists throughout the entirety of your code base, open source scanning can create a comprehensive list of all OSS packages in use plus any currently reported security issues.
Here are some additional resources for learning more about protecting your code and your organization from security risks:
• Our Secure Coding Learning Center has several short courses on understanding and combating specific code security flaws
• Learn more about creating a threat model and putting it into practice (PDF)