Security Bloggers Network 
SBN

Carrying Ambition Through Passion

Avatar photo by Thomas Segura on April 19, 2022

Hi Edouard! Can you tell us a bit about your background?

Carrying Ambition Through Passion

Hi! Well, actually my background with computers goes back a long way… As far as I can remember, I've always been trying to understand their magic: “how does this application work exactly?” From there, you start hijacking the system a bit, and… you end up wanting to work in cybersecurity! My first machine was one of the first consumer computers, an Amstrad CPC.

After the baccalaureate, I joined Epitech, a computer engineering school in France. As I was passionate about the low-level side of things, I was already familiar with the C programming language. But beyond technical skills, what I liked most there was the mindset: you learn how to learn. I was part of the Systems & Security Lab where I could work on research projects in my free time. In particular, we were investigating the use of GPUs for cryptographic computations (exactly the type of operation performed for crypto mining today!), which was pretty novel at that time.

Right after my studies, I started working as a cybersecurity expert. Because I was the first employee of the company, I also had the chance to build a team from scratch. I was kind of an “orchestra man” in this company, and this gave me the extraordinary opportunity to construct a security-oriented R&D department. I learned how to give meaning to a product by giving a global direction and telling people what to do. And I liked it.

That's when you knew you wanted to focus your career on the product side?

Yes. So I went back to work for SkyRecon Systems (now Stormshield), where I had worked on endpoint protection during my studies. This time, I became the solution Product Manager. This was really a revelation for me, that I could have completely missed if it wasn’t for a few very good bits of advice from some acquaintances. I’m still amazed at how a career path can depend on so little. I was lucky and brave enough to take the product leap when I had the opportunity. And I haven't looked back since!

Then I started working at Rohde & Schwarz Cybersecurity on a WAF (Web Application Firewall) solution. This is where I started working on AppSec: we were protecting running apps from vulnerabilities like the OWASP Top10. For me, the best part of AppSec is that you can advise the client on its digital transformation. This could be super strategic because you bring your expertise on topics such as: “to what point is the application supposed to scale?” or “How to transform a traditional product into a cloud-native one?”. And of course, “How the shift left transformation can open cybersecurity to the developers?”

Did you ever imagine that the problem of secrets sprawl called for the creation of a whole new range of AppSec products?

In a sense, yes. In my missions, I had to conduct a lot of customer interviews, and I was always trying to get what I call a "360 vision". And one thing that was often mentioned by CISOs or CTOs was the fact that their threat analysts had uncovered leaked SSH keys. It was a real pain point. So yes, I felt like there was something to be done. But other than that, I had no idea of the market, the actors, or the real size of the problem in the industry.

How did you first hear about GitGuardian?

I was first contacted by a headhunter, and I usually never respond to this kind of solicitation. But this time, he really managed to pique my curiosity. Then, I have to say the timing was quite perfect.

The first interview I had was really great, I instantly got a feeling of the company culture, and it started to consolidate my interest. Not long after, I had the opportunity to meet Guardians at a cybersecurity event. Shortly after that, I came to realize that several people in my entourage were telling me good things about GitGuardian or knew someone there, even in the US!
Everything was converging.

What were your impressions during the interview process?

Right away I understood that there was ambition for the company, but more importantly, there was a desire to give it the means to achieve great things in a structured way. Talking with Jérémy and Eric (GitGuardian’s co-founders), we spontaneously had passionate and deep discussions about how to transform the industry. Some key points for me were: 1.  US-focused, 2. Full DevSecOps, 3. Scale-up dynamism.

A French cybersecurity scale-up, created by passionate people to solve a no-bullshit problem, looking for a VP Product? For me, it was a no-brainer!

In my career, I worked for various small companies that got abducted by much larger conglomerates. This time, I wanted to see how far we could go propelled by VC funds!

How do you feel after your first weeks working here?

From a high-level perspective, the sense of detail prevailing at GitGuardian is quite impressive.
There is simply nothing left to the chance! Everybody is very focused on the little things and this tells you a lot about the company mindset.

Another thing I really appreciate is the asynchronous work culture. This exists by default, and everything is thought to ensure it works well. Another thing that can't be underestimated is the cross-services empathy. The collaboration flow is just great and while everyone is moving in the same direction you can find the time to help the others achieve their goals.

Also, I have to say I’m impressed by the diversity of backgrounds at GitGuardian! You'll meet with people coming from other industries or other roles, and this for me is a big sign of confidence. It means the company invests as much in mindsets as it does in hard skills, and that people’s know-how and passion do actually matter. Finding different levels of seniority is also a very good indicator of the structuring of the company.

What about life outside of work?

I like to say I’m a “fake” Parisian: I have a house in the countryside where I am part of the week, and I love this balance. Having a hybrid work organization is perfect for me. I was super lucky to be there during the first lockdown, first because I had bought it just a few weeks earlier, and then because I was coming back from a trip with the very last plane leaving!

When I’m not geeking, you can see me around on my mob, piloting a drone, or even cooking! The move inspired me to want to start, something that didn't appeal to me at all before!

Thank you very much for your time, Edouard.

Thanks!

*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog - Automated Secrets Detection authored by Thomas Segura. Read the original post at: https://blog.gitguardian.com/portrait-edouard/

Thomas Segura
Avatar photo

Thomas Segura

What You Need to Scale AppSec Thomas Segura - Content Writer @ GitGuardian Author Bio Thomas has worked both as an analyst and as a software engineer consultant for various big French companies. His passion for tech and open source led him to join GitGuardian as technical content writer. He focuses now on clarifying the transformative changes that cybersecurity and software are going through. Website:https://www.gitguardian.com/ Twitter handle: https://twitter.com/GitGuardian Linkedin: https://www.linkedin.com/company/gitguardian Introduction Security is a dilemma for many leaders. On the one hand, it is largely recognized as an essential feature. On the other hand, it does not drive business. Of course, as we mature, security can become a business enabler. But the roadmap is unclear. With the rise of agile practices, DevOps and the cloud, development timeframes have been considerably compressed, but application security remains essentially the same. DevSecOps emerged as an answer to this dilemma. Its promise consists literally in inserting security principles, practices, and tools into the DevOps activity stream, reducing risk without compromising deliverability. Therefore there is a question that many are asking: why isn't DevSecOps already the norm? As we analyzed in our latest report DevSecOps: Protecting the Modern Software Factory, the answer can be summarized as follows: only by enabling new capacities across Dev, Sec and Ops teams can the culture be changed. This post will help provide a high-level overview of the prerequisite steps needed to scale up application security across departments and enable such capabilities. From requirements to expectations Scaling application security is a company-wide project that requires thorough thinking before an y decision is made. A first-hand requirement is to talk to product and engineering teams to understand the current global AppSec maturity. The objective at this point is to be sure to have a comprehensive understanding of how your products are made (the processes, tools, components, and stacks involved). Mapping development tools and practices will require time to have the best visibility possible. They should include product development practices and the perceived risk awareness/appetite from managers. One of your objectives would be to nudge them so they take into account security in every decision they make for their products, and maybe end up thinking like adversaries. You should be able to derive security requirements from the different perceptual risks you are going to encounter. Your job is to consolidate these into a common set for all applications, setting goals to align the different teams collaborating to build your product(s). Communicating transparently with all relevant stakeholders (CISO, technical security, product owner, and development leads) about goals and expectations is essential to create a common ground for improvement. It will be absolutely necessary to ensure alignment throughout the implementation too. Open and accessible guardrails Guardrails are the cornerstone of security requirements. Their nature and implementation are completely up to the needs of your organization and can be potentially very different from one company to the other (if starting from scratch, look no further than the OWASP Top10). What is most important, however, is that these guardrails are open to the ones that need them. A good example of this would be to centralize a common, security-approved library of open-source components that can be pulled from by any team. Keep users' accessibility and useability as a priority. Designing an AppSec program at scale requires asking “how can we build confidence and visibility with trusted tools in our ecosystem?”. For instance, control gates should never be implemented without considering a break-glass option (“what happens if the control is blocking in an emergency situation?”). State-of-the-art security is to have off-the-shelf secure solutions chosen by the developers, approved by security, and maintained by ops. This will be a big leap forward in preventing vulnerabilities from creeping into source code. It will bring security to the masses at a very low cost (low friction). But to truly scale application security, it would be silly not to use the software engineer's best ally: the continuous integration pipeline. Embed controls in the CI/CD AppSec testing across all development pipelines is the implementation step. If your organization has multiple development teams, it is very likely that different CI/CD pipelines configurations exist in parallel. They may use different tools, or simply define different steps in the build process. This is not a problem per se, but to scale application security, centralization and harmonization are needed. As illustrated in the following example CI/CD pipeline, you can have a lot of security control steps: secrets detection, SAST, artifact signing, access controls, but also container or Infrastructure as Code scanning (not shown in the example) (taken from the DevSecOps whitepaper) The idea is that you can progressively activate more and more control steps, fine-tune the existing ones and scale both horizontally and vertically your “AppSec infrastructure”, at one condition: you need to centralize metrics and controls in a stand-alone platform able to handle the load corresponding to your organization’s size. Security processes can only be automated when you have metrics and proper visibility across your development targets, otherwise, it is just more burden on the AppSec team's shoulders. In turn, metrics and visibility help drive change and provide the spark to ignite a cultural change within your organization. Security ownership shifts to every engineer involved in the delivery process, and each one is able to leverage its own deep (yet partial) knowledge of the system to support the effort. This unlocks a world of possibilities: most security flaws can be treated like regular tickets, rule sets can be optimized for each pipeline based on criticality, capabilities or regulatory compliance, and progress can be tracked (saved time, avoided vulnerabilities etc.). In simpler terms, security can finally move at the DevOps speed. Conclusion Security can’t scale if it’s siloed, and slowing down the development process is no longer an option in a world led by DevOps innovation. The design and implementation of security controls are bound to evolve. In this article, we’ve depicted a high-level overview of the steps to be considered to scale AppSec. This starts with establishing a set of security requirements that involve all the departments, in particular product-related ones. From there it becomes possible to design guardrails to make security truly accessible with a mix of hard and soft gates. By carefully selecting automated detection and remediation that provide visibility and control, you will be laying a solid foundation for a real model of shared responsibility for security. Finally, embedding checks in the CI/CD system can be rolled out in multiple phases to progressively scale your security operations. With automated feedback in place, you can start incrementally adjusting your policies. A centralized platform creates a common interface to facilitate the exchange between application security and developer teams while enforcing processes. It is a huge opportunity to automate and propagate best practices across teams. Developers are empowered to develop faster with more ownership. When security is rethought as a partnership between software-building stakeholders, a flywheel effect can take place: reduced friction leads to better communication and visibility, automating of more best practices, easing the work of each other while improving security with fewer defects. This is how application security will finally be able to scale through continuous improvement.

thomas-segura has 59 posts and counting.See all posts by thomas-segura