Software Security for Developers

Introductions

Thomas Vitale: Hi everyone, and welcome to another episode of the GOTO Book Club. I’m Thomas Vitale, I’m a software engineer. I wrote a book about cloud-native development and Kubernetes, and I’m really passionate about all those subjects. Today I’m really happy to have Laurentiu Spilca with us. Laurentiu is a Java Champion and a book author — he wrote several books about Java and software development. Can you introduce yourself for the audience?

Laurentiu Spilca: Thank you so much, Thomas, and thank you for the invitation to the GOTO Book Club. I’m passionate about Java in particular, and also Spring and software development more broadly — covering everything from security to performance, troubleshooting, and more. I’ve written a few books, so if you know me it’s likely either because you’ve read one of those, or from my YouTube channel, which I also invite you to visit if you haven’t already. I’m very happy to be here.

Making Security Accessible to Every Developer

Thomas Vitale: Today we’d like to chat about your recent book, Software Security for Developers. How did you get involved with it? How did it start?

Laurentiu Spilca: This is actually a funny story. The idea came from my friend Adib, who is also very passionate about software security and an excellent expert. He asked me to help him continue the book, so we co-authored it together. I liked the concept from the very beginning — it presents the fundamental concepts of software security in an accessible way, focused from the developer’s perspective, with examples in Java and Spring. Even so, I would recommend it to any software engineer, because concepts like cryptography, encryption, hashing, and signing are the same regardless of whether you’re using Java, Python, C#, PHP, or any other language. Adib had put together a great table of contents and needed some help with time, so I joined. I accepted because it’s an excellent idea and a great piece of information that will hopefully help many developers upskill in the security domain.

Thomas Vitale: For developers, security has traditionally been a bit complicated — or maybe just not particularly exciting. As a developer myself, I know the thrill of working on new features, getting new functionality out, and seeing users actually use it. But security is so, so important. What’s your suggestion for developers to get more passionate about security and better understand its importance in modern software development?

Laurentiu Spilca: It’s a natural trend to be attracted to what’s visible — the features, the capabilities you’re building. And to forget about the non-functional criteria like security, performance, scalability, and maintainability. But a real professional always considers not only the functional part, but also the non-functional part. Security in particular tends to be avoided because of its perceived complexity. We treat security as very complex even in articles, documentation, and books — and that scares developers, especially entry-level ones. When they hear terms like cryptography, hashing, and encryption, they get scared and skip it entirely. They feel they can prove their usefulness through the functional side and push security aside. What we wanted to do with this book is present security in a simple way that doesn’t intimidate anyone. We tell the reader upfront that we won’t go into the mathematics of cryptography. When we discuss a cryptographic algorithm — whether it’s encryption, hashing, or something else — we explain it from the developer’s perspective, covering why something is recommended or not, in simple words with simple examples. Developers don’t need to understand elliptic curves or the prime numbers behind RSA to do their jobs. But they do need to understand how things work conceptually, because that’s how you make informed decisions about what to use in your applications. How can you choose between RSA and ECC if you don’t know the difference between them? Security should not be a subject reserved for top-level engineers. It should be a subject for everyone.

Thomas Vitale: I really like the focus on the developer perspective — being clear about what a developer needs to know versus what isn’t necessary, like the mathematics behind encryption algorithms. When you need to implement something like a custom OAuth 2.0 flow that isn’t supported out of the box by Spring Security, you really need to understand what encryption means, what a signature is, what the different types of algorithms are, and why some aren’t recommended. The difference between hashing and encryption is often confused, and so is the distinction between encoding and encryption. In Kubernetes, for example, there’s a concept called a Secret. You’d expect it to be encrypted, but it’s not.

Laurentiu Spilca: It’s just base64 encoded.

Thomas Vitale: Exactly. It’s called a Secret, so as a developer you might think: it’s base64 encoded, I’m safe — it’s a Secret. But it’s not. That’s why I think the way these subjects are explained in the book is so valuable — the topics can be easily grasped, with clear examples and code snippets that genuinely help understanding. And of course the examples are in Java, but as you said, these concepts really do apply across all languages. I’d like to talk about one of the things I like most in the book: the clear distinction between responsibilities and what a developer needs to know when it comes to security protocols. We have the protocol itself, which we typically don’t want to implement ourselves since standard libraries exist for that. But as developers we need to focus on the data formats used to exchange information — XML assertions, OAuth 2.0 JSON objects, and so on. That part can be really confusing. We have all these acronyms: JWT, JWS, JWE. So let’s talk about that. I really like how the book covers it — grounding the reader in encryption and signing algorithms before moving on to “now let’s use OAuth 2.0.”

Laurentiu Spilca: There’s so much confusion out there, and that’s one of the things we wanted to clear up. You gave a great example with Kubernetes Secrets. Here’s another: PasswordEncoder in Spring Security. Does it encode? Yes — but not in the conventional sense of the word. It should really be called a hash function. Encoding is a broad term that simply means changing something into something else. Hashing is more specific: it implies a one-way function where you cannot reverse the output to recover the input. I’ve seen articles on Stack Overflow, LinkedIn, and elsewhere that actually introduce more confusion rather than less, where the authors describe things incorrectly. We wanted to fix that.

Why Developers Should Never Reinvent Security Standards

Laurentiu Spilca: I’ve seen a lot of confusion around JWT as well. People sometimes treat it as if it were a security protocol, which it isn’t — it’s a data format, a JSON Web Token. I’ve even seen it confused with the authorization code flow from OAuth 2.0. This demonstrates that we don’t have a strong enough understanding of these things. And when developers don’t understand the standards, what often happens is that they reinvent them. Reinventing security standards because you don’t know them is dangerous, because you’ll inevitably miss details, and those missing details introduce vulnerabilities. Standards like OAuth 2.0, SAML, and OpenID Connect exist because they were built over time through the experience of many experts to represent the most secure known way of doing things like authentication and authorization. If you reinvent them, you’ll either end up rebuilding the same thing — which is wasteful — or you’ll introduce gaps. The same logic applies to using existing platform implementations. Platforms like Spring provide implementations of these standards precisely so that you don’t have to write them yourself. A bug in a widely-used library is far more likely to be discovered and fixed early than a bug in your own five-person team’s implementation. Using what already exists not only saves implementation time, it also gives you more security.

Thomas Vitale: Combining an existing implementation with a solid understanding of how the protocol works also makes it much easier to customize for special use cases. But I’ve seen the opposite happen too — developers build their own implementation from scratch because it seems simpler. They implement just what they need, and then it’s full of gaps because there’s so much they didn’t consider.

Laurentiu Spilca: As a consultant I’ve seen this more times than I can count. I’ve seen implementations of what the teams called a “token flow” — the client sends a request, gets back a JWT, and uses it for authentication. It looks like the authorization code grant, except it’s missing the credentials, the authorization code, sometimes the token expiration, and sometimes even the signature at the end of the token. That’s exactly what I mean when I say: know the standards, use the implementations your platform provides, and customize within the bounds of the specification. Those implementations are designed to restrict you precisely at the point where you’d be exiting the standard. That’s a feature, not a limitation.

Thomas Vitale: I also hear this a lot: “We’re using JWT security.” But JWT is a data format, not a security protocol. I really like how the book starts by grounding the reader in data formats, encryption, and signing, and only then introduces a protocol that uses those formats. And since you mentioned Stack Overflow — whenever it comes to security, it’s easy to find tutorials where security is simply skipped for the sake of the demo. So either there’s no security coverage in the article at all, or if it is specifically about security, it goes so deep into the mathematics that most developers lose interest. The book really fills a gap that exists in that space. I’m genuinely happy about it.

The Growing Security Risk of AI-Generated Code

Thomas Vitale: I want to bring up something you alluded to earlier. Generative AI is now part of development workflows. We keep generating code that we may not fully understand, and without knowing the security fundamentals, it’s very hard to review what gets generated — especially because AI models were likely trained on Stack Overflow answers and GitHub code that didn’t always follow security best practices. Just the other day I saw a story on Reddit about AI agents deleting entire file systems — and the joke was that all the times people trolled Stack Overflow with commands like “run this to delete your home folder” ended up in the training data of large language models. So now we have AI agents wiping file systems because someone gave them full permissions. Things are becoming more dangerous from a security perspective. I think learning these foundational topics has never been so critical. As a consultant, have you seen cases where AI-generated code caused problems because of a lack of security awareness?

Laurentiu Spilca: We’ve already started implementing AI-assisted development workflows across multiple clients, and there are many tools out there for this now. One of the most problematic patterns I’ve observed is when developers rush in, give the AI tool an overly broad context, and provide no specific direction. This is what I call vibe coding. You can’t just tell your AI agent “secure the endpoint” and expect a coherent result. If you do, it might use one framework for the first endpoint and something entirely different for the second. You end up with a patchwork of technologies that’s hard to reason about and likely full of security gaps. The right approach is to already have your design and implementation plan in place, and use the AI to write it faster. If you do that, you’ll be more productive. But to guide the AI effectively, you need to already know what you’re building. You can’t rely on the AI to give you the ideas. You run it — it doesn’t run you. The problem is that in many cases, the AI ends up running the developer, not the other way around.

Thomas Vitale: It’s going to be exciting to use this technology the right way, because it’s so easy to get code out quickly. But then that code needs to make it to production. We might get faster at initial implementation, but all the steps that come after — review, security audit, debugging — might actually become much slower and more dangerous if the foundation isn’t solid.

Laurentiu Spilca: AI is a multiplier of whatever you bring to it. Do it badly, and it will be even worse. Do it well, and it will make you better. You still need to know your craft. You can’t stop learning security just because the AI supposedly knows it. You need to learn it, know it well, and use the AI as a tool that makes you more efficient — while you remain the one who signs off on what gets committed. When you commit, your name is on the commit, not the AI’s. You take the responsibility for what gets into the codebase. The application is still built on your behalf.

Thomas Vitale: Exactly. As developers, we’re responsible for all the code we publish. We couldn’t blame Stack Overflow when we copied and pasted code from there, and we can’t blame AI systems for generating insecure code either.

Certificates, PKI, and Protecting Sensitive Credentials

Thomas Vitale: Another part I really like in the book is the section on certificates and PKI infrastructure. I’ve seen a lot of confusion among developers there too — the difference between a trusted certificate and a signing certificate, between a public key and a private key. And then there’s the problem of people exposing private keys and other secrets directly in source code. If you’re using an AI agent that reads your codebase, that problem gets amplified significantly.

Laurentiu Spilca: Certificates are genuinely complex if you go into the full details — there are multiple types of certificate authorities and different trust chains. And yet in the 21st century, even a non-technical person should have a basic understanding of what a certificate is. When you go to pay on an online shop, you should be able to look at the URL bar and check whether it’s HTTPS and whether the certificate is valid. Browsers are better at warning you now, but I remember when that wasn’t the case. Back then it was easy to intercept traffic by proxying HTTP to HTTPS, and that’s exactly how card details were stolen. The reason that’s harder today is because developers and architects implemented things like certificates, encryption, and public/private keys correctly. Developers and architects need to understand these concepts so that when they’re needed, they can apply them properly. You will be the one deciding where and how to use them in your applications.

Thomas Vitale: Especially in enterprise applications, where it’s common to have a private PKI with internal certificates. Understanding exactly how it works prevents really bad mistakes that can have a huge impact in production.

Book Availability and Resources

Thomas Vitale: The book Software Security for Developers is currently in the MEAP — the Manning Early Access Program — at the time of this recording. But we can expect the final version to be published very soon. Do you have any dates?

Laurentiu Spilca: The book is now in its last review phase, which means it will come back from a group of reviewers with a lot of feedback. I’ll address that feedback, polish the book, fix any language and grammar issues, and then the final version will be available. That said, you can already read it now. If you don’t mind the possibility of some minor English imperfections or the occasional sentence that’s still being refined, you can get early access on the Manning website right now. All the chapters are already there. There may be some changes after the final review, but the majority of the content is in place. And please don’t hesitate to reach out on social media if you have questions or feedback — the earlier the feedback, the better, because I can still incorporate it.

Thomas Vitale: So the book is available now at Manning. If you get it today you get the early access version, and you’ll automatically receive updates through to the final published version. For anyone who wants to reach out to you, can you share where they can find you?

Laurentiu Spilca: You can find me almost everywhere under my name. I’m most active on LinkedIn and YouTube — just ping me, I’ll accept the connection, and you can ask me any questions. On YouTube, if you’re following a particular topic in one of my videos, you can reach me in the comments section, and I also run live sessions where the live chat is always active. I’m very open to the community and happy to answer all questions and concerns.

Thomas Vitale: Thanks so much for being with us today. To recap: the book is titled Software Security for Developers, it’s already available in early access, and the final version will be published soon. Thanks again, and see you next time on the GOTO Book Club.

Laurentiu Spilca: Thank you very much. See you next time.