Closing security gaps in development workflows for ISO 27001 compliance

Key takeaways

 

• Software development and deployment involve multiple, often complex steps that can create opportunities for malware or vulnerabilities to enter a system and go undetected.
• Gaps in security can occur because of lax security enforcement, underappreciation of the possible risks a procedure or IT asset poses, or insufficient security testing coverage.
• The best protection comes from incorporating the entire development workflow and infrastructure into a detailed IT security plan that is enforced, monitored, and regularly updated.

The single most devastating cyberattack on US government agencies and major software companies – yes, the 2020 SolarWinds breach – was the result of attackers hijacking part of the software development supply chain of a third-party tools firm. Similar attacks against open-source projects have been successful as well, such as the one involving the NetBeans Java development environment, which for years unwittingly shipped malware that had been introduced into its build system. 

The bigger point, which is undeniably as timely and relevant as ever, is that every organization that develops software must develop a policy to secure its development pipeline. That holds true whether the software is meant for internal use or for customer-facing purposes, and it also covers web applications and mobile apps. The ISO 27001 standard, updated in late 2022, is an excellent starting point for understanding how to develop the protection orientation and policy for software development and, by extension, other IT activities.

The standard – specifically its Requirement 6.2 – calls for the development of a comprehensive, overarching information security policy and “applicable” objectives, “taking into account the information security requirements, results from risk assessment, and treatment.” Objectives should be measurable, monitored, communicated, updated, and made available as documented information, the ISO standard makes clear. When implementing policy changes, the IT organization must determine “what will be done, what resources will be required, who will be responsible, when it will be completed, and how the results will be evaluated.”

As these steps illustrate, the standard is not an abstract normative document but rather a framework that requires active implementation. ISO 27001 makes clear that implementation of the security policy must be a living process that is properly communicated, enforced, and updated. Such vigilance can help staff spot and immediately address unanticipated gaps in security coverage and staff knowledge.  

So what kind of gaps in security coverage are we talking about?

Where does your code come from?

Developers frequently search the web for answers to coding problems they encounter – problems as simple as how to use a data structure in a given language or as complex as how to implement a difficult algorithm. Forums such as StackOverflow are popular for these kinds of discussions, where contributors who answer queries will post the full code intended to remedy the problems at hand. In turn, many developers will copy and paste the supplied code, unchanged, into their product code.   

The possibility of unwittingly copying and pasting malicious code is clearly a serious threat. But there are two other hidden risks. The first has to do with licensing: If the copied code comes from an open-source project, then the code is subject to the terms of an open-source license. In the most harmless scenario, this requires a statement distributed with the product acknowledging that some of its code is used under a specific license. However, if the applicable license is a “copyleft” license (such as the widely used GPL and AGPL licenses), the code of the entire application must be released to all users. Obviously, this requirement could have serious consequences and may rule out some commercial usage. Sophisticated static code analyzers today can spot code that is likely taken from an open-source project. To minimize the risk of non-compliance, a policy must be in place to use such tools on a regular basis across the entire codebase. 

A related threat arises when developers bring in dynamic dependencies that incorporate third-party code into the application. This is a particularly common practice in JavaScript code in web applications. In this setup, the code is brought into the program every time the application is run. While there is a risk that the code could be modified for malicious purposes, it can also be modified with no evil intent and prevent an application from running correctly or even running at all. In an extreme example, back in 2016, a developer deleted from his personal repository a simple 11-line function that enabled characters to be added to the start of a string. Thousands of web applications, including some at Facebook, Netflix, and Uber, suddenly stopped working until the deleted lines were restored. 

Have you tested that app in real life?

Developers understand the importance of testing their code: Unit tests, integration tests, and user-acceptance tests are all established practices. But security, if it is to have no gaps, should also test running web applications. Dynamic application security testing (DAST) scanners search for entry points, vulnerabilities, and other exploitable weaknesses as the application operates and interacts with users. While DAST tools can and should be run after deployment, restricting them to this stage gives attackers the chance to exploit a vulnerability introduced in a new release. The smarter scenario is to also test each web app in a staging environment that faithfully duplicates the exact deployment environment and allows a DAST tool to search for vulnerabilities before moving into production.

The issues typically found in such pre-deployment verification, which may not show up even in extensive static testing, represent another gap where unexpected vulnerabilities could occur despite prior testing and code reviews.

Eliminating security gaps

The security gaps discussed in this article are typical of many development organizations, but dozens more can occur along the software development life cycle. Because these gaps are hard to spot, much less foresee, IT managers are encouraged to use established methodologies to secure their development pipelines. The updated ISO 27001 standard and accompanying ISO 27002 guidelines document present a thorough overview. Companies that are ready to systematize their security may also consider adopting the practices spelled out in version 1.1 of the US National Institute of Standards and Technology’s Secure Software Development Framework, which can help close many security weaknesses.