When companies like Microsoft or Oracle develop software, they have massive teams who’s only job is to try and find bugs in the software. They also have made significant investments automated tools to help with software quality assurance. Still Microsoft usually patches 10-20 new bugs month after month. Oracle often patches 100 bugs a quarter.
Given these example company’s results in spite of major investments in technology and people, what does that mean for the average software development shop that doesn’t have the tools, personnel or budget that these major software shops have.
Security Compass, a Canadian company that assists Fortune 500 companies with software security issues, conducted a study of financial institutions application security practices.
Here are some of the findings of the report:
- While most financial institutions have created security development lifecycle practices, very few of them can actually validate how well they are doing at following them.
- Three out of four rate application security as a critical or high priority
- 89% use the BSIMM (Building Security In Maturity Model) while almost all of the others use some form of framework or standard.
- When it comes to metrics to measure how effective these frameworks are, most do not have a robust KPI measurement process. Many measure raw vulnerability counts (77%), which is a very basic measurement.
- Less than half measure how long it takes to fix bugs.
- Only a little more than a third track whether developers actually use the security tools called for in the policies.
- The study showed that 58% of the banks use some third party software, but less than half of the financial institutions require their vendors to have a security development lifecycle process or even an application security policy.
These results are from financial institutions where security and process are usually front and center. If this is the reality for organizations which have a high security awareness profile, how does the average organization rank on security process and practices. Likely, those organizations don’t rank very well.
Smaller development shops – say with less than 50 developers likely don’t have a security development lifecycle (SDLC) process at all. The likely don’t have automated tools to detect bad coding practices and they likely have a small (to no) quality assurance department. If they do have a software QA department, that department is likely looking for functionality problems and not security issues and is not trained to find security problems.
If the software is developed under a development contract, that contract likely does not specify the requirements for an SDLC process or for any of the the other security processes that large software development shops have.
In addition, they likely do not conduct third party, independent, penetration tests to attempt to find those security issues.
As a result, it is likely that those custom applications are a hacker’s dream gateway into your organization and you likely will never know.
Companies that develop their own, or contract for the development of, custom software development – including web sites – need to up their game if they want to keep hackers out. If they don’t, the hackers will continue to quietly thank them.
Information for this post came from Dark Reading.