Far too many organisations run web and mobile apps that are vulnerable to targeted attacks. They may be using unpatched libraries and software components, they may access personally identifiable information (PII) unencrypted, or they may simply have been developed in a way that security was not baked into the software development pipeline.
According to Bola Rotibi, a research director at CCS Insight, the reason web applications are so often vulnerable is down to the way development teams operate. “There are too many basic security vulnerabilities because development teams, and, let’s be fair, their security auditors, leave themselves wide open,” she says.
For instance, not covering the tracks to common folder locations where sensitive information is held is like leaving the door open for hackers. “Disconnects in the security posture between different teams present gaps that can be exploited. For too many organisations, there is still too little sharing of security policies or the checklist of common vulnerabilities on which teams are regularly caught out,” says Rotibi.
Need for speed
If GitLab’s latest survey of 4,500 software developers is anything to go by, testing is the main reason for delays in the release of new code. But thorough testing is essential if organisations want to minimise the risk of releasing insecure code that could be exploited by a malicious actor.
Anecdotally, the developers who took part in the survey felt they needed to “shift left” in terms of their security stance. In other words, developers are starting to recognise the need to become more security savvy and apply security best practices to their coding.
Encouraging developers to spend more time thinking about the security of the software they write cannot happen in isolation, especially if demands from the business call for a high cadence in releases of new digital functionality – but attitudes are changing
Testing for vulnerabilities in code needs to be baked into all phases of the software development process. Some experts recommend submitting code for external testing before going live with new functionality.
“If you don’t [carry out] external penetration testing, you are heading for disaster,” warns Roy Castleman, managing director of EC-MSP, a London-based IT support firm for small and medium-sized enterprises (SMEs).
Encouraging developers to spend more time thinking about the security of the software they write cannot happen in isolation, especially if demands from the business call for a high cadence in releases of new digital functionality. But attitudes are changing.
Business priorities
“As business owners, we know very little about the inner workings of our systems. It’s important to trust your team – and, in this case, it’s more important to verify. Your team may well be excellent marketers and designers, but security is a whole different ball game. Even when you have a security team working for you, it’s critical to get things double-checked,” says Castleman.
A study from analyst Forrester reveals that while application security flaws are prolific, management is at least acknowledging the problem. Organisations have started to realise that the solution lies not just with security teams, but with developers as well, note the authors of Forrester’s State of application security, 2021 report.
The Forrester research shows that for 28% of security decision-makers, improving application security is a top tactical IT security priority in the coming year – this being the most commonly cited initiative. According to the study, 21% of security decision-makers plan to prioritise building security into development processes.
Forrester says well-implemented application security tooling can narrow the gulf between developers and security professionals. This enables developers to seamlessly address security issues without leaving their own development pipelines. One example of a software development and deployment pipeline with security baked in is being used at Domino’s Pizza to maintain high code quality and ensure IT security does not hinder the pace of software development.
A pipeline for secure software development, deployment and operations
Domino’s Pizza takes a hybrid approach to software development, which means application security bridges internally developed code and software developed externally.
Speaking to Computer Weekly prior to this year’s virtual Infosecurity Europe event, Lee Whatford, chief information security officer (CISO) at Domino’s Pizza, described the company’s DevSecOps process, which hinges on a security model that provides oversight and visibility across the software development and deployment pipeline, with any issues resolved during product testing.
“We have internal platform developers and a third party which does application development,” he says, adding that whether code is developed internally or by the external software development company, the internal developers are empowered to ensure the code produced is secure.
The company has developed a security model that offers oversight and visibility. The model covers containers and the security infrastructure, and incorporates governance, skills and visibility. By providing a level of visibility, Whatford says developers are able to improve their knowledge and awareness of security, which allows them to code more securely.
Discussing the challenge of embedding a security mindset in the software development process, he says: “In the software development pipeline, the most important step is to work as close to the software development process as possible. The developers have to be agile for the business so we have to work at pace, yet still retain checks and balances on how they run infrastructure and deploy code.”
Whatford says these checks and balances ensure developers do not accidentally publish code to the wrong place. The security model effectively provides a playground in which to develop and deploy code securely, without infringing on the agile software development and deployment process.
Automation is used extensively in the software development phase, to test for application vulnerabilities and automatically reject code that fails certain test criteria. These automatic scans rate security risks. For instance, the code being tested may have a medium level of vulnerability risk. For Whatford, this automated rejection helps to reinforce the security training message. “It means the developer’s code cannot get through the software development pipeline and production environment,” he says.
On the IT infrastructure side, publishing code is automated through another pipeline. This ensures that the application development and infrastructure teams can work effectively together with the IT operations teams. Such segregation of duty in terms of security controls is required by Domino’s Pizza to comply with the PCI DSS card payment standard.
Whatford says Domino’s Pizza is in the process of maturing its security model, adding more detailed processes. The aim is to have a set of rules from an operations perspective that enforces a secure by design approach.
“If we have visibility of what’s happening and have a baseline of what good is like, we can quickly spot anomalies and misconfigurations,” he says, adding that this will enable Domino’s Pizza to prioritise issues and fix serious security risks rapidly. “When there are a million things to do, it is about governance and business risk management. We need to prioritise fixes,” adds Whatford.
Domino’s Pizza has now started deploying automatic remediation of IT configuration issues, based on a minimum baseline of high-priority configurations.
Changing attitudes
By its very nature, when hand coding applications, there is a higher chance that the programmer may introduce new vulnerabilities. But if the GitLab survey can be considered a litmus test of developer attitudes, software developers are beginning to take more responsibility for security.
“For all those who care about meeting the expectations of clients, whether they are inside or outside the organisation, one of your top priorities should be to reduce risk in the web applications you develop” Bola Rotibi, CCS Insight
For the developers GitLab spoke to, common methods used to improve the security of code include code reviews, static code analysis and monitoring live applications, along with security scans of open source libraries and containers, and risk analysis in the design phase of the project.
For Domino’s Pizza’s Whatford, secure coding starts with a security model, which developers can use alongside automated testing, to ensure they write clean, secure code, and understand why the testing suite is rejecting the software they submit. This is a learning process: as they develop more secure applications, the tools are less likely to reject their code.
It is this idea of striving to reduce coding errors that software developers need to take heed of. CCS Insight’s Rotibi says: “For all those who care about meeting the expectations of clients, whether they are inside or outside the organisation, one of your top priorities should be to reduce risk in the web applications you develop.”
