Intro by Rodolphe Mas, CEO of Glev
I’ve had the pleasure of working with Marc for a little less than a year. What strikes me most is not only his technical expertise but also his ability to take a step back and see the broader picture of what it means to be a security engineer in a software company. His insights reflect both a deep understanding of security challenges and a strategic mindset that goes beyond day-to-day operations.
In this conversation, we talked about his journey from full-stack engineer to leading Application Security at Launchmetrics, an enterprise software vendor. We discussed what triggered his move into security, the challenges of transitioning from development to AppSec, what the role really looks like day to day in a software company with demanding customers, and how he sees application security evolving. Especially in a world increasingly shaped by automation and AI. We also touched on his experience working with Glev as a design partner and how tooling can (or cannot) help AppSec teams scale.
What follows are Marc’s answers, written in the first person, as the synthesis of our discussion.
From building software to protecting systems: how cybersecurity became my path
I didn’t start my career in security. I started as a software engineer, like many people in this field. Years ago, even before finishing my degree in computer systems, I was already working in software consultancies. During university, I joined a research group at the University of Girona, where we signed a contract to build a blockchain-based e-voting platform.
That project became a turning point. I moved from the research group into the startup itself as CTO, while also handling DevOps responsibilities. Later, I joined Launchmetrics as a full-stack developer. Alongside all of this, I spent nearly two years teaching cybersecurity in a technical high school program — which deepened both my technical foundations and my passion for explaining security concepts.
Eventually, Launchmetrics gave me the opportunity to formally join the security team and become an Application Security Engineer. I didn’t hesitate.
My interest in cybersecurity was sparked mainly by blockchain. Working with cryptography opened my eyes to how powerful — and necessary — strong security foundations are. That’s where I discovered the broader dimensions of security: confidentiality, integrity, availability. What we often summarize as the CIA triad.
Many people focus only on protecting data. But I quickly realized that keeping systems available when they’re needed is just as critical. Data that is perfectly encrypted is useless if your platform is down. The same goes for integrity: protecting what should never be altered.
Understanding how all these dimensions work together is what truly pulled me into cybersecurity. I saw that security wasn’t just a technical layer : it was fundamental to how systems should be designed and operated.
Making the transition: from shipping features to managing risk
Moving from development into AppSec wasn’t just a technical shift, it was a complete change in mindset.
As a developer, you work in a very tight, collaborative environment. You’re constantly syncing with product owners, designers, QA, and other engineers — usually within a small team of five to ten people. Interaction is essential to getting anything done.
In security, collaboration is still crucial, but in a different way. My work doesn’t depend on one single team anymore. Instead of being deeply embedded in one product, I now interact with many teams across the company. My scope became much broader.
Technically, the context exploded. Before, I focused on the product I was building. Now I need to understand many systems, technologies, processes, cloud infrastructure, third-party services, and workflows. I had to expand my ownership and be prepared for almost everything the company uses.
But the biggest shift was mental: I moved from building to reviewing, alerting, and mitigating risk.
One thing I personally love about AppSec is that I still build. But I build security programs, controls, and tools that my own team and the company use every day. There’s something very satisfying about creating something you directly rely on, rather than only delivering features for end users.
Another important realization was that security isn’t solely my responsibility. My role is to evaluate risk, expose weaknesses, and propose controls, but reducing risk belongs to the entire company. Developers, product teams, designers, QA, legal, marketing, everyone influences security every time they introduce something new.
Security is not a task. It’s a mindset.
What being an AppSec leader really looks like in an enterprise software company
At Launchmetrics, we build enterprise software for demanding customers. That means security, reliability, and compliance are not optional. They’re part of the product.
On a day-to-day basis, my work revolves around risk.
We map company assets — infrastructure, code repositories, employee access, products, third-party providers — and analyze the threats that can impact them. For each risk, we define controls to mitigate it. Then we prioritize based on real impact, customer expectations, and business reality.
When nothing urgent happens, my daily work is about:
- Assessing risks across systems and teams
- Designing and enforcing security controls
- Automating protections wherever possible
- Monitoring logs, infrastructure, access, and abnormal behavior
- Training and supporting teams when something isn’t aligned with security standards
Of course, there are also incidents: phishing attempts, bots constantly hitting our WAF, suspicious behaviors, and smaller issues that need fast response.
And then there’s compliance : SOC 2, ISO certifications, customer audits. Together with legal and other teams, we materialize security into concrete controls that meet those standards. Compliance might sound boring to some people, but I actually enjoy it: it’s how security becomes real and measurable.
One underestimated part of AppSec is communication.
Every time something isn’t secure by default, we need to explain why it matters, how to fix it, and how to avoid it in the future. It’s constant education.
Because people are usually focused on their own tasks: building features, shipping campaigns, closing deals. Security is about helping them integrate risk awareness naturally into their work.
Where AppSec is heading: automation, mindset, and shared responsibility
From both my developer and security perspectives, the biggest trend is clear: automation.
Just like DevOps transformed development, automation is transforming security.
More and more security controls will live directly inside development pipelines. Strong rules will automatically block risky code before it reaches production. Tools will continuously scan, review, and enforce standards, not after deployment, but at the source.
Security needs to move back to the beginning of the chain.
Fixing vulnerabilities after release is always slower, more expensive, and riskier than preventing them from being introduced in the first place.
But there’s an even bigger challenge beyond tooling: making security a company-wide responsibility.
Developers are often executors of product requests. But every new feature, every workflow change, every integration introduces risk. Not just code changes.
We talk a lot about unpatched versions and vulnerabilities, but less about how product decisions can expose customer privacy or increase attack surface.
Security isn’t only about scanners. It’s about:
- How features are designed
- How data flows are imagined
- How complexity grows across systems
Reducing complexity across the company is one of the most powerful security strategies.
And then there’s AI, a true double-edged sword.
AI helps developers build faster, but it also helps attackers automate attacks faster. The same tools that improve productivity can dramatically increase threat capabilities. That makes automation and strong security controls even more critical.
In the coming years, AppSec engineers will spend less time manually reviewing code and more time designing automated systems, risk frameworks, and security-by-default environments.
How Glev helped our AppSec approach
Glev helped us uncover some of our weaknesses, but also better understand issues we already knew existed and how to remediate them.
Glev as a company is moving toward the automation part I mentioned earlier, introducing review processes inside the security development pipelines of the teams.
I see them as the dev cybersecurity assistants.
