An interview with The Good (Samuel Hernández, ERNI Spain) on the digital frontier
In a world of rapid digital development and constant cyber threats, The Good takes a different approach. Not the fastest coder or loudest voice, his work often keeps systems secure. In this exclusive interview, we explore what it truly means to build safe software today.
.experience: How do you define your role in a development team?
The Good: I see myself as the one who ensures the foundation is solid before the house is even framed. My role is to think ahead – not just to deliver functionality, but to anticipate what might go wrong and build safeguards before code is ever executed. I work to make sure that what we ship is not just performant or scalable, but secure by design. It’s less about preventing attacks reactively and more about designing systems that are resilient from day one.
When does security begin in your process?
Before the first commit. Security starts with the architecture. Before we code, I want to know what data we’re handling, where it lives, who accesses it and what could go wrong. I use threat modelling frameworks like STRIDE to visualise potential vulnerabilities and build mitigations directly into the design. If security is an afterthought, it becomes technical debt. My job is to bake it in from the beginning.
Can you walk us through your daily toolkit?
My tools evolve depending on the project stage, but some staples remain. For early development, I define coding standards that avoid the most common pitfalls – no hardcoded credentials, no unchecked inputs, no insecure dependencies. In parallel, I implement static analysis tools (SAST) that scan code on every push. During integration, I add dynamic analysis (DAST) to test live applications for behavioural issues. I also rely on infrastructure-as-code validations and container scanning to make sure deployment environments are as trustworthy as the code itself.
I use dependency scanners linked to public vulnerability databases, and I maintain a detailed Software Bill of Materials (SBOM) for every build. Every package we use is accounted for, versioned and monitored. If a vulnerability is discovered in an upstream library, we already know exactly where it lives in our system.
What’s your stance on secrets and credentials management?
Secrets should never be visible. No passwords in plain text, no API keys pushed to repositories. I integrate secrets management tools like Vault or cloud-native solutions to keep sensitive data encrypted and access-controlled. I apply the principle of least privilege rigorously – no user or process should have more access than strictly necessary. I also automate secrets rotation and monitor access logs. Secrets are treated like weapons: locked away, carefully tracked, and used only when necessary.
Beyond tools and code, what defines a secure developer?
Discipline. Secure development isn’t about knowing every exploit – it’s about being methodical. It’s about making deliberate choices at every step: validating inputs, enforcing type safety, logging responsibly, thinking about failure modes. I also invest time in documentation, not just for my team today, but for whoever inherits the code tomorrow. Security thrives on clarity, and documentation is how we pass down intentions and warnings.
But more than that, it’s about culture. I advocate for secure practices in code reviews. I host post-mortems that aren’t about blame but about learning. I train team mates to spot red flags. My goal is not to be the only one thinking about security – it’s to make sure everyone does.
How do you handle legacy systems or insecure inheritances?
With patience and a clear strategy. I start by mapping the system and identifying high-risk areas. From there, I conduct triage: what needs fixing now, what can be mitigated, and what should be deprecated. I focus on isolation, input validation, and patching what we can, while lobbying for long-term reengineering when necessary. It’s never ideal, but legacy systems are a reality. The key is to reduce their attack surface incrementally without paralysing the product roadmap.
What does success look like for someone in your role?
Ironically, success often means silence. No breach. No urgent hotfixes. No headlines. It means systems that just work – and keep working – without users ever realising the countless things that could have gone wrong but didn’t. It also means knowing that if something does go wrong, we have logs, alerts and rollback mechanisms in place. Success is invisible until it’s not.
Any misconceptions about secure development that you often encounter?
Yes, plenty. The biggest one is that secure development is slow. It can feel that way at first – especially in teams accustomed to speed over structure – but long term, it’s faster. You avoid firefighting. You reduce rework. You build trust with clients and regulators. Another myth is that security is someone else’s job – usually an external team or an auditor. I reject that completely. Security is everyone’s job, but developers are on the front line. We have the power to prevent, not just respond.
How do you balance security with product pressure and deadlines?
That’s one of the hardest parts of the job. The pressure to deliver fast is real, and security often looks like friction to people outside the process. What I try to do is integrate security into existing workflows, so it doesn’t become a blocker. Automated tests, pre-commit hooks, lightweight reviews – these go a long way. But I also work to build credibility. When teams see that I’m not just pointing out problems but helping prevent future chaos, they begin to value that input. The balance comes from partnership, not from enforcement.
Have you ever failed? And what did you learn from it?
Absolutely. I’ve missed things. We all do. Once, a third-party package I trusted introduced a critical vulnerability in a patch release. I had SBOMs, but I wasn’t enforcing version locks strictly enough. We caught it fast, but it was a wake-up call. Since then, I’ve treated third-party code with even more scrutiny. Failure teaches you humility – and it teaches you to listen more to your systems, your alerts and your intuition.
What sets a cybersecurity champion apart from other developers?
A cybersecurity champion isn’t just someone who knows how to write secure code – they’re someone who brings that mindset into the team and advocates for it consistently. What sets them apart is not technical brilliance, but presence. They’re the ones who ask uncomfortable questions in sprint planning, who raise their hand when a shortcut might become a liability. They don’t just fix vulnerabilities – they help prevent their recurrence. Champions are bridges: between developers and security specialists, between the business and the tech. They create a culture where security is part of the definition of done.
Final thoughts?
I’m not a hero. I don’t chase threats. I don’t look for glory. I build for durability. My job is to make sure what we create can be trusted. Because in the end, trust is the most valuable currency in tech. And it’s earned one secure line at a time.
Explore also our eBook CRA from regulation to reality below to learn how to secure digital products.
