The Tao of Software Engineering

by Thomas Segura on August 8, 2022

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

Yes sure! Although I'm not really sure how far I should go back… Well, let's try to summarize: after high school, I studied engineering and that first led me toward software architecture. During these first years, I had the opportunity to do my first internship in security: I was performing OWASP-based testing on the web application and found it quite funny, to be honest! I also explored project management governance, things like ISO 27001 certifications, etc. during an internship, but it wasn't technical enough for me.

After that, I flew to Ireland to do my master's at the University of Dublin: Digital Investigation & Forensic Computing.

I learned a lot about reverse engineering, cyber certifications, the law, and investigations in general, including how to question witnesses! My final exam consisted in presenting the results of my investigation to a fake court, and my professor—a former Scotland Yard agent—was playing the defense attorney. I can tell you that the debates were though!

The studies were exciting, but I eventually ended up doing something else. The problem with this career path is that the opportunities are quite limited: basically, it's either the army or Interpol. And 80% of the investigations revolve around pedocriminality, which explains the turnover…

Sponsorships Available

Anyway, after that I decided to start as a cybersecurity consultant, doing mostly pentesting for big clients.

Is it when you discovered the problem of secrets sprawl?

Well, I'd say yes and no. Of course, we were regularly advocating for sane management of credentials, but what we generally see on the ground is often "all or nothing": it is either super robust, with strong policies already in place, or it is almost open-bar and no serious thinking has gone into the problem.

I was working on application security, and for sure we knew it was a problem. We just weren't aware of the sheer size of it.

What made you switch to development after that?

I learned a lot in consulting but, technically, it wasn't very rewarding. Whenever I found something interesting I wanted to dig, I was told there was no time for it—because we were always understaffed.

Besides, I was already doing a lot of programming. In particular, I've been working for years on a personal project to analyze gaming stats. We don't realize it, but games produce so much data, that looking for patterns in this haystack is almost like looking for secrets in source code! All this to say that the switch was quite natural for me.

How did your first hear about GitGuardian? Can you tell us more about your position?

I was looking for a new Tech Lead position when I stumbled upon GitGuardian's offer which looked interesting given my background… but at the same time, I also found another offer related to sports, which I'm fond of! And honestly, I went first with that one… Before changing my mind soon after! But of course, I had to re-apply to a new position.

This time it was for working as Engineering Lead in the Rogue 1 squad (Engineering teams are organized in tribes and squads to cut out the functional perimeter and dispatch responsibilities efficiently, ndlr). We are in charge of maintaining the GitGuardian Public Monitoring product. In particular, I've been working on clients' custom webhooks, to make sure events are properly repatriated, and doing a lot of codebase rationalization.

How was the interview process?

I had my first interview with Eric (the CTO, ndlr) and it was a big YES: I directly recognized that he knew what he was doing, both strategically and from an engineering point of view. All the other interviews just served as a confirmation after that, but I was already impressed by the maturity level displayed.

I think I made the right decision in joining GitGuardian.

What makes you say that? What did you enjoy the most during your first month?

As I said, for such a young company, I was surprised to see such maturity on many critical points: internal documentation, which is already consequent and self-sufficient (a good thing!), development and HR processes, and code quality relative to the features. I was very happy to be able to find my path autonomously with the documentation! And the other very pleasant thing I would say is the emphasis on balance between quality and velocity, which is excellent.

What would you say about the atmosphere in your team?

I appreciate the goodwill of the dev team, and I hope this will continue as we grow! I really like to share my knowledge and take the time to help out. Plus we hold regular knowledge sessions once or twice a month about interesting topics: it can be a new tech we've been trying out, an external library, improvements, and technical decisions or an introduction to a security topic.

I already did one on Gitflows, and another based on a talk I gave at FOSDEM at the start of this year.

Tell me more about that, you are a conference speaker?

Yes! I started doing that out of the pure desire to share my knowledge on very specific topics, that I really tried in a professional context. I want to be able to answer when I'm asked how something will function in a production setting or at scale.

So far I participated twice in the Django and twice to PyCon France editions. The last one was for the Python track at FOSDEM, and it was about managing feature flags in Django.

What would you say to someone who is considering joining GitGuardian?

I'd say go! That being said, to be a good fit, I think a person needs to be curious because there is a lot of information to digest at first. The best way to take your marks is to navigate by yourself. Taking initiatives and asking questions are definitely going to help too—no worries, even seniors often forget things!

Aside from the classic engineering stuff, I would tell this person that we work in close collaboration with the product and marketing teams, and the clients of course—which is great because nothing beats seeing that the product is used!

Finally, I would also reassure her that knowing cybersecurity is not a requirement. There is enough information sharing to arouse curiosity and ramp up softly. But it is still the heart of the business, so a minimum interest is important.

Any hobbies?

I'm a sports addict and I've been for some time now! Kung fu, capoeira, judo, but also swimming and climbing… I've been doing that for as long as five years old… and I have just validated my 1st level as a yoga teacher.

Martial arts are supposed to bring something to your life, beyond the pure physical effort. They are super beneficial for things like controlling emotions, mental health, and respect towards others. In my job, I think it is a great quality to be able to let the ego go and just accept criticism from "masters" for what it really is: the way to improve!

Thank you for your time!

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-mehdi/

August 8, 2022August 8, 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