In most companies, the business relies on some internal software development teams to translate their needs in a reliable and secure product that could bring them some competitive advantage. However, the most recent cyber security reports available still suggest that software is mostly unsecure with more than 80% of all software carrying high and critical vulnerabilities despite an increasing risk awareness.
Why is this? Because security is frequently bolt on rather than built in. Let’s have a closer look at the typical ways for a product owner, a developer team and a CISO to interact during a project and see how frustrating it can be...
The Product Owner
As a product owner, you rely on developers to bring a competitive advantage to your company. You write stories and expect developers to write code and algorithms, to connect systems and produce value for your customers. In this phase, all your efforts are aimed at describing what your product will do. Unfortunately, out there, some bad guys are already waiting for your innovative solution to be released. They hope some vulnerabilities will allow them to steal some data to be sold on the black market.
The Developers
Based on all the information provided by your product owner, developers have started writing code. They solved complex issues and came out with an innovative solution. It has been a hard teamwork, and they are proud of the end result. Their product has a nice interface and works like a charm. It’s quite ready for production. Now all is needed is a security approval.
The CISO
This is usually the time where you, as a CISO, learn about the existence of this new exciting project. It is now your responsibility to protect the business from the inherent risks carried out by innovation. Your best option is to ask for a penetration test, which will eventually find some high and critical vulnerabilities, as usual under such circumstances. The software must be remediated: it’s a No Go for security.
Consequences
As a development team, you have received the report from the penetration test, and you are required to fix the software before it is used in production. Not only chances are you’ll need some level of code rewriting and architectural changes, but at the end of the process, the software must be entirely retested.
From the Product Owner perspective, it’s way too expensive. Budgets are limited, hence remediation is rarely complete. It ends up being a trade-off between risks and costs. This possibly explains why more than 80% of all software is still at risk.
At this stage, for the CISO, the only way to reduce the risk for the company is to add more and more compensating controls.
A different mindset
But here’s the good news: companies are not doomed to produce risky software. By introducing some automated security tests in their SDLC (software development lifecycle) they can produce safer software at a lower cost, because remediation is less expensive when addressed in the development phase.
Not only it will reconciliate the single visions of business, security and development, but it will start a positive revolution where security is everyone’s concern as it is achieved by collaboration rather than pushed on.
If you want to learn more about how we can support your challenges with our Secure SDLC method , we invite you to join our conference during Infosecurity Belgium 2020 “Developers: your first line of defense against cyber threats".
About the author:
With a developer background, Eric Lefèbvre has spent more than 20 years working with web development teams. Before he joined Approach as a Secure Delivery Lead Consultant, he was successfully running the international security champions program at Thomas Cook.