Telecom & Technology Consulting
In software development circles, there’s an issue that everyone acknowledges, but is never (or rarely) actually discussed. It’s how products often get into customer hands with bad code. A new report shows that over 80% of applications come into the world with insecure code.
By no means is there anything malicious behind this lack of quality control. Developers typically face arbitrary deadlines set by the sales and marketing departments. They want the product completed fast so it can get to market. That’s the root of the insecure code. And that’s why the actual testing of code becomes less of a priority.
But there’s a backstory. Engineering and security are not necessarily working in unison. They have conflicting interests. For example, engineering can fall behind schedule and feel pressure to fix the code while security simply needs a certain metric for the code.
Some will point out that open-source code libraries can help to greatly eliminate this problem: Open-source shrinks the amount of code that developers have to write. This is true. The problem is that using open-source piles on some security holes. The code becomes less secure, as well as the security of both the software dependencies and the third-party libraries. All of a sudden you can usher in unforeseen threats in the development process, which the team may not realize if they don’t detect them in the initial development stages.
In most cases, when it comes to security, the product is scanned before it goes into the market. While this action can eliminate security vulnerabilities, it’s often done much further in the process than needed. Security issues can easily slip into the product. This is why it’s extremely critical to be mindful of the entire development cycle, and not just focus on the final product.
Major cyber attacks are constantly front-page news these days. Every developer and security expert knows about them. You have to scratch your head and wonder why these types of vulnerabilities still end up in some software products.
The good news is that you can bring security into the process at an earlier stage. The idea is to have security implemented as part of the overall development plan – from the beginning rather than down the line when you begin testing.
This new thinking can include hurdles, as developers often have a way they prefer to work. But that doesn’t mean you can’t overcome those hurdles. On the contrary.
Some organizations are building teams to develop a number of application interfaces, including those for version checks and vulnerability scans. Since they host these APIs internally, developers have easy access to them in a secure manner.
In addition, many organizations have adopted a DevSecOps approach, which aligns development and operations in their respective roles. Experts have shown how the growth of DevSecOps tends to create more secure software. Even more, DevSecOps move the focus away from security as a stand-alone issue and more towards security as part of overall product quality.
Insecure code and software bugs are inherently part of the development process. No one is to blame. The key, moving forward, is to proactively address how to improve security. The sooner you make security part of the process, the better the overall quality of the product.
