Securing Your Legacy and Future in Software Development: More Lessons from "Alice & Bob Learn Secure Coding"

The image shows a wooden table with a laptop on top. The laptop has an open lid displaying a graphical user interface, and there is a mug of coffee next to it. The table appears to be in a café or similar setting, indicated by the presence of other tables, chairs, and decorations. In the background, there's a window with blinds partially drawn, and outside, one can see what looks like an urban environment with buildings and trees. The atmosphere suggests a relaxed, casual workspace.

This post is part of an ongoing series on the books that I have read as part of my continual professional development (CPD). All of my CPD posts are available at the following link: Continual Professional Development

We often get caught up in the excitement of new technologies, the latest frameworks, and shiny tools. As leaders and decision-makers in software development, it’s easy to focus on the cutting edge. However, a truly secure and resilient software ecosystem isn’t solely built on the newest innovations. It’s deeply rooted in fundamental principles, and the book “Alice & Bob Learn Secure Coding” by Tanya Janca offers a powerful reminder of these core truths.

As a technology consultant, I’m constantly drawing on insights from diverse sources; not just technical documentation, but also from books that offer broader perspectives on quality, risk, and human behaviour. The wisdom within “Alice & Bob” resonates deeply with the challenges faced by teams of all sizes, and I wanted to share some of the most impactful quotes that have shaped my thinking. These aren’t just technical pointers; they are strategic considerations for anyone responsible for the safety and success of their software.

Prioritise Security in the Development Lifecycle

We need to schedule security activities into the official project schedule. We need to plan enough time to mitigate any security bugs or flaws that we find in our product. It is not enough to just schedule a security activity to happen; we need to have enough time to fix the things that we will most certainly find during the security activity.

This is a cornerstone of practical software security. Far too often, security is treated as an afterthought, squeezed into an already packed timeline. This is a fundamental error. True security isn’t a quick fix; it requires dedicated time and resources.

As leaders, we must champion the inclusion of security activities (such as threat modelling, code reviews, penetration testing) as integral parts of the development lifecycle, not as optional extras. This isn’t about slowing down progress; it’s about building a more robust and ultimately faster development process by addressing vulnerabilities early.

The reality is that security bugs will be found. Ignoring this inevitability is naive. By proactively planning for remediation, we demonstrate a commitment to quality and risk management. This also sets a positive culture within the team, signalling that security is valued and that developers are empowered to take ownership of security.

Invest in Developer Security Training

If you need the software developers where you work to create and maintain secure applications, you have to teach them how. You cannot assume that they will show up already knowing how or caring (no matter their age or where they learned to program). If you plan for them to learn “on their own time and dime,” you are bound to be very, very disappointed. Your organization needs to support them in their learning, and that means training.

This crucial point is often overlooked.

We can’t simply expect developers to inherently possess secure coding skills. The software development landscape is constantly evolving, and security best practices are equally dynamic. Investing in training and ongoing learning opportunities isn’t just a nice-to-have; it’s a necessity.

This support should encompass not only technical training but also fostering a security-conscious mindset. Providing developers with the knowledge and tools they need to write secure code is an investment that yields significant returns. It reduces the likelihood of introducing vulnerabilities, improves the overall quality of the software, and empowers the team to take ownership of security. This isn’t a one-off event; it’s an ongoing commitment to professional development.

Address Legacy Application Security

If you look at the security posture of the software across any mature (older than 5 years) organization, it is always the legacy applications that create the majority of business risk, not the brand-new ones. I don’t mean that there are more legacy apps than new ones, and, therefore, there are more bugs. I mean that software ages badly from a security perspective.

Each year that goes by, our industry takes security more seriously, and therefore, we become more secure with each new release, and everyone is becoming more knowledgeable about security as we continue to have breaches, and it is less likely that old applications have had thorough testing when compared to new ones.

This offers a sobering yet important perspective on the longevity of software. While we often focus on the security of new projects, the risk often lies within our existing systems. Legacy applications, built in an era with less stringent security awareness, are frequently riddled with vulnerabilities that haven’t been addressed. This presents a significant and often underestimated risk to any organisation. Addressing legacy security isn’t always straightforward, but it’s a critical part of a comprehensive security strategy. This might involve dedicated remediation efforts, careful risk assessment, or even the consideration of modernisation or replacement. Ignoring these older systems is a gamble we can’t afford to take.

Maintain Security Post-Release

After we release an application, we continue to be responsible for it. We must continue to test it on a regular basis because we know that software does not age with great poise.

The development process doesn’t end with the deployment of an application. In fact, it’s arguably where the real work begins. Software is a living entity that needs continuous monitoring and maintenance to remain secure and reliable. Regular testing, including vulnerability scanning and penetration testing, is essential to identify and address any new weaknesses that may emerge. This post-release vigilance is a fundamental aspect of responsible software ownership. It demonstrates a commitment to ongoing quality and security, and it allows us to adapt to evolving threats. Neglecting this crucial phase is a recipe for potential breaches and reputational damage.

Foster a Culture of Lifelong Learning

When you decide to work in technology, you agree to be a lifelong learner. You cannot excel in this field if you do not learn new things.

This sentiment extends beyond the technical skills required for a software career. It’s a vital mindset for anyone leading or managing software development. The technology landscape is in constant flux. Staying current with emerging threats, new security paradigms, and evolving best practices requires a commitment to continuous learning, both for ourselves and for the teams we lead. As leaders, we should foster a culture of curiosity and encourage our teams to dedicate time to professional development. This could involve attending conferences, pursuing certifications, or simply dedicating time for research and experimentation. A learning organisation is a resilient organisation.

ℹ️ Note

I’ve written about the importance of continual learning several times, but the most post is are When Your Team Thinks They’re Done Learning: A Tech Lead’s Guide to Reigniting Growth.

Promote Knowledge Sharing

Every single person in our industry has the responsibility to do their jobs as securely as they can, but most of them do not think that sharing information with others is part of that responsibility. It is my hope that you and I can change that mindset… Please help me on my mission by sharing knowledge with others whenever you have the chance.

The above highlights a crucial aspect of building a stronger security community. Security shouldn’t be a siloed concern; it’s a collective responsibility. Sharing knowledge, experiences, and lessons learned, both within and across organisations, is vital for raising the overall security bar. Creating an environment where open communication and knowledge sharing are encouraged is something we can all champion. This could involve participating in industry forums, contributing to open-source projects, or simply sharing insights with colleagues. By working together, we can collectively strengthen the security of the entire software ecosystem.

ℹ️ Note

I’ve written about communities of practise inCommunities of Practice: Your Secret Weapon for Breaking Silos and Accelerating Learning. These, effectively, 10x the continual learning across your teams.


Ready to boost the secure coding knowledge across your teams?

These quotes from “Alice & Bob Learn Secure Coding” offer valuable insights for anyone leading or managing software development. They remind us that security is not a destination but an ongoing journey that requires a blend of strategic planning, technical expertise, and a culture of continuous learning and collaboration.

If you’re looking for support in navigating these complexities and building a more secure and resilient software development process within your organisation, I’d be delighted to discuss how my strategic technology consulting services can help. Explore how we can work together to strengthen your team’s security posture here: https://rjj-software.co.uk/services/, or by using the contact form below.

We'll never share your name with anyone else.
We'll never share your email with anyone else.
Providing a subject can help us deal with your request sooner.
Please be as specific as possible; it will help us to provide a more specific response.
Un-checking this box will ensure that your data is deleted (in line with our privacy policy after we have dealt with your request. Leaving this box checked will auto enrol you into our email communications, which are used for marketing purposes only.