Joining the GitGuardian Talent Acquisition Team

by Thomas Segura on June 22, 2022

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

Yes, of course! Let's start from the beginning: after high school, I went to study human resources at an IUT and then management at the Montpellier IAE. At the time, I wasn't sure if I wanted to do recruitment, I was more interested in social management. However, I had the chance to go to Quebec for a year to do a more business-oriented master's degree. The courses were half in English and to perfect my skills I then decided to go to New York and then the UK where I worked as a general assistant – there I started doing recruitment but it wasn't the same as here!

After returning to France, I decided to pursue a path that combined business and recruitment by joining a recruitment firm. This is where I really started to learn the secrets of qualification: how to find candidates and pitch them effectively for the position.

I spent 3 years at this firm as a consultant specializing in HR, Payroll, Finance, and Purchasing, among other things. This is where I gained more experience, particularly from my colleagues who had significant seniority.

How did your first hear about GitGuardian?

Although at that time I was quite far from the world of start-ups, what I liked the most about working in a recruitment firm was the prospecting aspect. At one point I was contacted by a French scale-up that had the right words to pique my interest in this new world for me. It didn't work out, but I was recommended on Kommunity (a peer-to-peer recommendation platform) and from there I had my pick of the litter! But it was GitGuardian that stood out for several reasons.

Sponsorships Available

What drew you to the company?

First of all, I really wanted an innovative company, not just "disruption" all over the place. Even though I had no technical background, I quickly understood the issue that GitGuardian was tackling and immediately got hooked.

I felt the atmosphere was both warm and serious when I first met Louise. The speed at which the recruitment process took place (just 3 weeks) was also a big green light: as a recruitment specialist, it was clear to me that if it was working well then the company must be in good shape.

What did you enjoy the most during your first month?

The tools, work methods, and thinking at GitGuardian are clearly some of the best in the business. I appreciated the responsiveness at all levels and the involvement of everyone in my own development. I realized that the company already had a good brand image among developers (I often hear the phrase "oh, I know what you're talking about!" when I talk to them for the first time). Ultimately, devs are not as difficult to recruit as people think! If we can capture their attention with a quality product and show that development is at the heart of the company, it's actually quite easy!

How did you manage to overcome imposter syndrome?

It's simple: I went all out from my first week! I immediately sought to meet as many profiles as possible: SRE, devs, understand the stacks, job descriptions, talk to as many people at GitGuardian (that's also very much appreciated, techies take the time to explain their job to non-technical people). I also learned new recruitment methods, which were all new to me. Anyway, I would say that the syndrome didn't last very long because I'm comfortable in fast-paced environments!

What would you say to someone who is considering joining GitGuardian? In particular, someone who has no experience in the tech industry?

In my opinion, the question to ask is "am I curious? Do I have an entrepreneurial spirit?" In my case, the answer to these two questions was clear. Today, if you are at all curious about what the future holds, you will inevitably end up working in tech. "Software is eating the world" as they say! Might as well get used to it quickly.

As a developer, what should you not do during an interview?

Even if developers are becoming more and more aware of the importance of soft skills, it is still important to remind them that these skills are essential. My personal advice is to never "skip" the first interview (first contact). I see a lot of technical profiles asking to meet a manager or lead right away, and that is a red flag! Making a good first impression with the Talent Acquisition Manager is important, as we always have a say in the recruitment process.

What would you say about the atmosphere in general in the company?

I was immediately surprised by the very serious atmosphere at GitGuardian, which is the opposite of the start-up stereotype of having beer-pong tournaments all the time. I would even say that the open spaces are calmer than what I was used to in my previous job. But that doesn't mean that it's boring! The Guardians also know how to have fun when it's appropriate. It's just very pleasant to work in such an environment. I would also say that the main quality that I noticed when I arrived here is sharing. I love intellectual stimulation, discovering new professions, and working in an environment like this is ideal.

Any hobbies?

I have two big hobbies: science fiction and sports! I do a lot of running and working out in the gym and I challenge myself. Since I can't be an astronaut, which is what I dreamed of as a child, I also do some diving. My dream would be to buy a boat and go diving and fishing all day long!

Thank you for your time!

Thanks!

If you are interested in a new adventure, please consult our career page to find your next challenge!

*** 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/joining-tam/

June 22, 2022June 22, 2022 Thomas Segura Guardians

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 48 posts and counting.See all posts by thomas-segura