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 all know that in software development, security isn’t just a thought: it’s a fundamental pillar. As a consultant, I consistently advocate for a proactive, security-conscious approach, and recently, I re-read Tanya Janca’s book, “Alice & Bob Learn Secure Coding” and was sincerely impressed by it. This isn’t just a technical deep dive; it offers profound insights applicable to anyone leading or shaping the direction of a technology-driven organisation.
The book’s core message resonates strongly with the challenges faced by team leaders and decision-makers. It’s about building a culture of security from the ground up, embedding secure practices into the very fabric of the development lifecycle. I wanted to share some of the most impactful takeaways and quotes that have sparked significant reflection and informed my approach to technology strategy. I also wanted to mix in some of Tanya’s most impactful quotes from a recent episode of The Modern .NET Show on which she guested.
The Path of Least Resistance
When we make the path of least resistance the secure path, everyone wins. If it is possible to make the easiest way to do something the most secure way to do it, we are more likely to get the results that we want! Wherever possible, create a secure road that leads to the most secure way forward for the user.
This quote is a powerful reminder of the importance of user experience and security not being mutually exclusive. Often, developers instinctively take the quickest route, which can inadvertently introduce vulnerabilities. As leaders, we need to champion secure defaults and design patterns that make the secure choice the obvious one. This might involve incorporating security libraries by default, streamlining secure coding practices within our frameworks, or even making secure options the pre-selected choices for users.
Prioritising Security Investments
Buy, borrow, build, in that order. Always buy a system that does the thing you need and only then, if one is not available that meets your requirements, borrow one. Borrowing can mean reusing code from another team, another organisation, or using features within your framework. As a last resort, we build from the ground up, writing each part of the code ourselves. We prioritise in this order to save time and money but also because prebuilt systems and framework features generally have more security attention and thus are a more secure option. It’s a win-win all round.
This principle is crucial for resource allocation. While the allure of building everything in-house can be strong, it often leads to duplicated effort and potentially less secure solutions. Leveraging well-established, security-audited systems and platforms is a far more efficient and often safer approach. As decision-makers, we must consider the long-term security implications when choosing technology partners and platforms.
The Importance of User-Friendly Security
When you are building an application with a username and password fields, please allow users to copy and paste to those fields. Password managers need to be able to paste into the fields. In the past, there were misguided security professionals who preached against this, believing that allowing pasting into password fields would make it easier for malicious users to brute-force those systems.
In reality, it caused people to not be able to use extremely long, complex passwords because they were forced to type them out manually, which resulted in a lot of mistakes and quite a bit of frustration for the end users. As a result, end users are likely to use shorter, less complex passwords for sites that disallow pasting, which means their accounts are less secure. This is not a win for anyone. To avoid this, all you need to do is not disallow pasting into password fields.
Please and thank you.
This seemingly small point highlights a common pitfall in security thinking: prioritising theoretical risks over practical usability. Security measures should not unduly burden users or force them into insecure behaviors. By embracing user-friendly security, we can empower users to make safer choices without creating unnecessary friction.
ℹ️ Note
I’ve talked about this in the past, and included a list of resources showing why it’s a bad idea to block password managers. You can read that post here.
This is not just a couple of software developers complaining about not being able to copy-paste passwords, it’s a current best practise in application security.
Addressing Technical Debt Proactively
If you don’t make time for technical debt, it will make time for you! Many software-related security incidents you face will be more difficult to respond to if you have a large amount of technical debt. When you have a fast release process, low technical debt, and the ability to release virtual patches, your team can be a lean, mean, incident-responding machine.
Technical debt is often viewed negatively, but it’s not inherently bad. The problem arises when it’s allowed to accumulate unchecked. Proactively addressing technical debt (by refactoring, updating dependencies, and improving code quality) significantly strengthens an application’s security posture and makes incident response much more manageable. As leaders, we need to allocate resources to tackle technical debt as a crucial part of our development process.
The Power of Backend Validation
With the help of a web proxy such as Burp Suite or Zap, anyone can circumvent the front-end JavaScript of a web application and send requests directly to the web server/backend. As a result, validation, sanitisation, or escaping on the front end is never enough from a security perspective. The final decision must always be made on your web server/backend.
Front-end security measures are valuable, but they are not a substitute for robust backend validation. Attackers can easily bypass client-side protections. Ensuring that all data is validated and sanitized on the server-side is a fundamental security principle that cannot be compromised.
The Value of Focused Security Learning
I wanted to focus on the idea of: if I teach you how to do the right thing, I don’t need to get you to memorize a ton of vulnerabilities. Because if you learn specific defences for specific vulnerabilities, you’ll spend forever doing that, like whack-a-mole, right? Versus if you learn all the main important defences, almost all the vulnerabilities don’t apply to you any more.
Instead of trying to equip developers with a comprehensive list of vulnerabilities (a near-impossible task), focus on teaching them core secure coding principles and defence mechanisms. This provides a more sustainable and adaptable approach to security. A strong foundation in secure practices empowers developers to address new threats as they emerge, rather than constantly chasing individual vulnerabilities.
Simplifying for Security
Limit complexity whenever possible. Complexity often leads to problems. Simplify whenever possible.
This principle applies not only to code but also to system architecture and security controls. Complex systems are inherently harder to secure and more prone to errors. By striving for simplicity, we reduce the attack surface and make it easier to understand and maintain security measures.
💡 Tip
This is another example of keeping things as simple as possible, which was also the main thesis of Jerry Nixon’s points in season 8, episode 3 of The Modern .NET Show,
Jerry Nixon is the Principal Product Manager at Microsoft, focussing on the tooling and Developer Experience around Azure SQL Server.
Building Secure Defaults
In the book, actually, I have a big section about secure defaults and building paved roads. And in it, I’m like, "I know this is manipulative, but what if we manipulate our users for good? What if all the defaults are super secure? Come on, let’s do it."
This quote encapsulates a powerful shift in mindset. Instead of relying on users to actively configure security settings, we should proactively build secure defaults into our systems. This “paved road” approach makes secure choices the default, reducing the likelihood of misconfiguration and improving overall security.
Ready to Ensure that your teams practise secure coding?
These insights from “Alice & Bob Learn Secure Coding,” alongside Tanya Janca’s compelling narrative in a recent episode of The Modern .NET Show, offer valuable lessons for anyone responsible for the security of software development within an organisation. I always champion these principles to help our clients build resilient and secure applications.
Ready to build a more secure future for your team? I offer strategic technology consultation services to guide organisations through every stage of their technology journey, with a strong focus on security. Explore how we can help you embed security into your development process. Visit https://rjj-software.co.uk/services/ (or use the contact form below) to learn more and book a consultation.