When discussing Agile development, I like to say that the only people who achieve success advocating Agile 101 process adoption by the book are the people actually writing and selling the book. The rest of us need to be flexible when employing the process in the real world of software development.

Agile is not a methodology to be used for fixing things that aren’t broken or for forcing process for the sake of process. In other words, to be successful, we need to be agile with Agile.

Challenges of Agile Adoption

One of the biggest challenges of the Agile adoption framework is identifying real and useful motivations behind the theories and not thinking of the process as a checklist of immutable instructions. Any well-applied software development process should enable, not impede, success.

Security professionals should adhere to these processes for specific and quantifiable reasons, not simply because managers mandate they do so. The processes are designed to deliver high-quality, secure software in a rapid environment, and to eliminate traditional pitfalls common to the waterfall, functional specification, extended delivery planning and development strategies of yesteryear.

For the process to function as a valuable and real enabler for the team, we need to shape and adopt it to our real-life software delivery needs. Early struggles to adopt may be due to the natural difficulty of change; often its value isn’t immediately recognized. In those cases, it’s important to work through the growing pains and give the new approach a fair shot by inspecting and adapting the adoption process as you go.

Eventually, the team will either discover real efficiencies and value from its efforts or conclude that particular aspects of the process just aren’t working. At that point, don’t be afraid to jettison or reconfigure the unsuccessful parts and simply move on.

Inspect and Adapt

To make Agile work, the principle of “inspect and adapt” should be applied to all aspects of the process — from user story formation, definition, breakdown and design to iteration planning, estimation and daily scrum execution.

People typically think of Agile adoption as it applies to process execution — how are my user story breakdowns going? What can we change to make our estimations more useful? How are new requirements or critical support engagements affecting my iteration commitments? Usually, these topics make up the bulk of a sprint retrospective discussion. In that regard, it’s a very useful approach and mindset to iteratively improve the scrum team’s execution from sprint to sprint.

The inspect-and-adapt approach should also be employed in the actual delivery of the functionality, specifically in testing cycles, as new pieces of user stories are implemented. We too often approach a sprint as a mini-waterfall, essentially allotting the first two-thirds or more of the iteration for development and the last one-third or less for stabilization testing and documentation of features.

That approach frequently leads to user stories being unfinished at the end of sprints and activities either bleeding into the next sprint or becoming deprioritized or shuttered entirely at the following planning session. In addition to making the scrum team’s commitment level less predictable at the next sprint planning, this results in lower quality and less secure software being released with each sprint.

Forrester Research Report: Secure Apps at the Speed of DevOps

No Surprises

The Agile process doesn’t like surprises, lingering questions or other unknowns throughout an iteration. More than anything, that applies to the final software product being built and delivered, especially as it relates to the level of quality and security expected from the software.

To achieve an acceptable level of security, quality code must be iterative throughout the sprint, meaning that we must perform testing throughout the process to find bugs, defects and other vulnerabilities early. We can’t wait until each user story is fully completed, and we certainly can’t wait until the very end of the sprint. This is challenging because it can take considerable time to write code, and testing teams generally have a limited number of dedicated quality, testing and security resources.

The theoretical book on Agile 101 would advise that anyone on the scrum team can take on any task or workflow throughout the sprint. Therefore, everyone on the team would a potential tester. In the real world, however, we know it typically doesn’t work that way, at least not in any sustainable fashion. You can only rob Peter to pay Paul so many times before you’re going around in circles, reducing the effectiveness of both your testing and coding efforts.

DevOps to the Rescue

Here’s where automation and DevOps can save the day. Like anything else in Agile development, it can be hard to find time to invest upfront costs in these kinds of exercises. However, a stronger focus on these elements should not come at the expense of getting your regular work completed. They should be viewed as critical tools for a scrum team that wants to operate efficiently and predictably to deliver secure, quality code with every iteration.

Of course, this mindset can run a bit contrary to the traditional Agile philosophy that directs a scrum team to adjust constantly. But in many ways an initial investment in automation and DevOps, combined with ongoing investments in maintenance, updates and supporting automation and a commitment to the DevOps model, can serve as perfect compliments to that development theory.

Having the right automation in place allows coders to code furiously and enables dedicated testers to build and execute acceptance test and use cases. Most importantly, however, it allows for continuous testing throughout the sprint, almost from the minute the first line of code is written. This is critical to ensure the highest level of secure, quality code goes out the door at the end of each iteration.

To learn more about improving your organization’s DevOps effectiveness, consult our complimentary Forrester Research report, “Secure Applications at the Speed of DevOps”.

More from Application Security

X-Force Identifies Vulnerability in IoT Platform

4 min read - The last decade has seen an explosion of IoT devices across a multitude of industries. With that rise has come the need for centralized systems to perform data collection and device management, commonly called IoT Platforms. One such platform, ThingsBoard, was the recent subject of research by IBM Security X-Force. While there has been a lot of discussion around the security of IoT devices themselves, there is far less conversation around the security of the platforms these devices connect with.…

4 min read

Patch Tuesday -> Exploit Wednesday: Pwning Windows Ancillary Function Driver for WinSock (afd.sys) in 24 Hours

12 min read - ‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities.Figure 1 — Exploitation timelineHowever, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack surfaces can…

12 min read

Backdoor Deployment and Ransomware: Top Threats Identified in X-Force Threat Intelligence Index 2023

4 min read - Deployment of backdoors was the number one action on objective taken by threat actors last year, according to the 2023 IBM Security X-Force Threat Intelligence Index — a comprehensive analysis of our research data collected throughout the year. Backdoor access is now among the hottest commodities on the dark web and can sell for thousands of dollars, compared to credit card data — which can go for as low as $10. On the dark web — a veritable eBay for…

4 min read

Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers

17 min read - Overview In this post, IBM Security X-Force Red offensive hackers analyze how attackers, with elevated privileges, can use their access to stage Windows Kernel post-exploitation capabilities. Over the last few years, public accounts have increasingly shown that less sophisticated attackers are using this technique to achieve their objectives. It is therefore important that we put a spotlight on this capability and learn more about its potential impact. Specifically, in this post, we will evaluate how Kernel post-exploitation can be used…

17 min read