Extreme programming (XP) is an agile software development framework that aims to produce higher quality software and higher quality of life for the development team.

In 2003, one of the first controlled studies highlighted the benefits of extreme programming (XP) (Abrahamsson, 2003). This study showed how the extreme programming technique improved accuracy by 26% and productivity by 12 locs/hour.

And that was in 2003.

Today's development methods are considerably more efficient. Yet, they don't fully consider the role and importance of security. So, what's the point of an ultra-agile development process if its just going to turn up bugs later, and then require the team to cycle back, patch, re-launch, etc.

A better alternative? Securing code as early as possible.

Below are some techniques adopted from the extreme programming approach that benefit application security.

Techniques Adopted From Extreme Programming (XP)

While there's endless ways to integrate security into your SDLC, we'll be focusing on three techniques:

• Pair Programming
• Continuous Integration (CI)
• Test-First Programming

Pair Programming

Pair programming is having two developers work at the same workstation. They'll write, debug or explore code together, taking turns doing tasks. As one developer works, the other watches to observe, learn and support.

Benefits:

• Removes knowledge silos to increase team resiliency
• Collective code ownership can increase developer engagement with the project
• Reduces the incidence of bugs through continuous code review
• Efficiency gains through a short feedback loop, more representative of a live code review
• Increased learning and opportunities for communication

Challenges

• Risk of disengagement or 'watch the master' behavior. This happens when one developer takes primary control over the project and the other watches, without practicing or learning.
• Communication breakdowns can happen when the developers aren't talking through their processes, or they disagree on an approach for building or debugging

Continuous Integration (CI)

While not part of programming, continuous Integration is a growing favorite for teams that are scaling their code deployment and provides some great benefits to ensure security. In continuous integration, smaller code changes are immediately tested and added to a larger code base. It's an automated process where code changes from multiple contributors are merged into a single software project. Usually, continuous integration is also adopted alongside continuous delivery (CD), so that code is tested and shipped out in small, quality batches.

Benefits

• Automated integration to immediately test code
• Opportunity to catch and fix issues earlier
• Requires fewer changes to be incorporated after the build

Challenges

• Takes discipline to commit to fixes as they're found
• The possibility for flawed tests. This potential increases when tests are poorly written, outdated or not suitable for a particular app
• Issues with version control. Most CI/CD processes are developed for a specific version of an application, and would need to be reconfigured for new versions

Test-First Programming

Test-first programming (also called test-first development) works in a cyclical process of automated unit tests to identify issues with code before writing it for production. The steps of this process are:

1. Write a failing automated test
2. Run failing test
3. Develop code that allows it to pass the test
4. Run test
5. Repeat

Benefits

• Reduces feedback cycle for developers to identify and resolve issues
• Decreases number of bugs that are introduced into production

Challenges

• Steep learning curve to understand and use the process
• Requires more up-front coding than other development methods
• May be difficult to get buy-in from senior management if they are resistant to change or do not understand the benefits of the 'backward' approach

Extreme programming is one of the most specific frameworks, and can be great for any company that is considering adopting an agile methodology. However, security cannot be forgotten in the process. Security should be proactively considered in the methods that your organization adopts. Regardless if you are choosing to use experimental programming or an alternative method, you can reflect on the options above to imagine how security can be best integrated into your SDLC.

Scientific References:

Abrahamsson, P., 2003. Extreme programming: first results from a controlled case study. Proceedings of the 20th IEEE Instrumentation Technology Conference (Cat No 03CH37412) EURMIC-03,.

Erdogmus, H., Morisio, M., & Torchiano, M. (2005). On the effectiveness of the test-first approach to programming. IEEE Transactions on Software Engineering, 31, 226-237.

Ge, X., Paige, R., Polack, F. and Brooke, P., 2007. Extreme Programming Security Practices. International Conference on Extreme Programming and Agile Processes in Software Engineering, [online] 4536, pp.226-230. Available at: <https://link.springer.com/chapter/10.1007/978-3-540-73101-6_42> [Accessed 16 September 2021].