The right software security practices can prevent many future security problems, and there is an increasingly realisation that software development security needs a cradle-to-grave approach, not just focusing on solving problems once they become apparent.
There is still a long way to go and no-one can claim this is easy to address: the increasing complexity of modern software development environments, not to mention the sheer volume of code and other digital assets being created, often in continuous, fast-paced environments, exacerbates the challenge.
Also, security has traditionally not been hard-baked into the mindsets of developers, who are focused on creating beautiful code. That is changing, with DevOps becoming endemic, bringing in its wake DevSecOps and a realisation that software needs monitoring at every stage, together with the ‘Shift Left’ movement — where developers take on responsibility for tests at an early stage.
However, keeping up with all that effort requires more automation, with testing and code inspection tools that carry out as much of the work as possible in background mode. Software developers do not have the time – and probably not the inclination — to become testing experts.
Does software quality equal software security? It depends
Sorting through the noise
There are some caveats here: automation is great, but not if it just creates a huge volume of test data noise. What matters is to focus on the tests that will have a real business impact and to combined automated continuous testing with smart analytics. We are beginning to see machine-learning being built into automated testing tools and while it is early days, it is going to make a big difference in the future.
Some markets — particularly compliance-driven or safety-critical — are also adopting coding standards, guidelines that give developers confidence they are building safe, secure and compliant code.
Coding standards are particularly relevant for some of the more complex programming languages — C++ in particular — which while introducing unprecedented scope for innovation and flexibility, also allow for more interpretation, which can lead even the most skilled developer to inadvertently introduce an error. Again, automation is key, especially for huge codebases and complicated embedded software projects, so static code analysis is increasingly introduced to reduce manual effort and associated risks.
IBM says automation is the next big step in cyber security
Open source security
Open source is just software and therefore has security issues and bugs just like proprietary software. For example, OpenSSL is perhaps the most used open source security software in the world, yet still occasionally has critical issues. This means careful management and support is a necessity for open-source, not just a nice-to-have. Another example is Git, the widely-used version control tool, but enterprises have more sophisticated security requirements than the open source community designed into this developer-focused tool.
Another factor to consider is that open source is low-cost to acquire and often bypasses procurement, so therefore flies under the radar. Organisations need to find ways to ensure that Git and other open source software complies with company security policies.
However, successful open source services (OSS) policies require more diversity in expertise, the costs of keeping up may tempt corners to be cut, all of which contributes to potential security issues. To deal with this, there is a growth of OSS providers, but choose wisely: inconsistent SLAs across different components in the stack, lack of clarity around responsibilities, and too many vendors involved, or not being able to adapt fast enough to the latest technology introductions.
The comprehensive IT security guide for CIOs and CTOs
Application security
When it comes to securing applications, consider threat modelling, a process that identifies but also prioritises potential threats from an attacker’s perspective. Questions to ask might include: what kind of data would an attacker be seeking? One popular threat model is STRIDE, which can be used in tandem with the DREAD risk assessment framework: this helps work out how likely is the threat to happen, the threat’s potential consequences, and whether the risk can be tolerated.
For web applications, the Open Web Application Security Project Foundation, has published its top 10 list of the most common and critical security risks and this is an excellent reference source. Each threat is ranked by its agents, exploitability, prevalence, detectability, technical impact, and business impact.
The top 10 OWASP help with API security, too. There is a shifting emphasis towards securing them at every part of the lifecycle, starting with the development stage. Once an API is published and a problem arises, there is little or even no time to take remedial action. In the same way that any new website is likely to get multiple attacks within launch, the same applies to APIs.
How can organisations take advantage of the API economy?
Improving API software development has to start with culture; people need to be aware of their roles in mitigating risk and prioritising security. This applies to both internal and external contributors (who may have little development expertise — anyone can build APIs). Putting in place processes that can be automatically and consistently enforced across all current and future APIs helps enforce good security practice, as will an API gateway (but choose one that supports multiple API types).
There are some recurring themes here: getting the right cultural attitude in place, automating as much as possible, and having sight of the bigger picture. That last point is an important one: visibility into other people’s work and their impact in a development project goes a long way towards better security.
Software is becoming more complex, with bigger codebase and types of asset: the security threat landscape will grow too, so taking a multi-faceted approach to a more secure development environment needs to be prioritised.
