Innovating at the Intersection of Ops and Product

by Thomas Segura on April 7, 2023

This month we had the pleasure of chatting with Dhia, ProductOps manager and data analyst.

Hi Dhia! Let's kick off by starting from the beginning: what's your role, and how would you summarize what you do?

Hi! Since September 2022, I have been a ProductOps Manager & Data Analyst at GitGuardian. It’s a hybrid role between the Ops and the Product team, which is very interesting. Another aspect that I find exciting about the position is that it’s a new role within GitGuardian but also an emerging one in France, which leaves room for creativity in defining the scope and missions related to the function.

My role is basically threefold: first, I’m in charge of leveraging product data to get insights about how our customers are interacting with our products and how we can better address their needs.

Second, I intervene in initiatives around efficiency and enablement. In short, I’m in charge of building the right system to help product managers and designers work more efficiently and have a bigger impact through continuous improvement of our tools and processes.

Sponsorships Available

Third, I work on program management and alignment. For example, I intervene in strategic cross-department projects involving the product to make sure that all the stakeholders are aligned on the objectives and that all impacts on the different teams are assessed and well managed through shared responsibilities. In short, I ensure that there is a 360° vision during the entire project.

The product team was GitGuardian’s fastest-growing team in 2022 (quadrupled from 3 to 12!), so there is a lot going on. We have 2 open positions at the moment, so we encourage you to apply!

What does your daily routine look like?

Well, I can describe what my weekly routine looks like! Each week starts with meetings with the Ops, Data, and Product teams to discuss the progress of the different projects and the planning of the week. Then, about 50% of the time is devoted to individual progress on tasks and deliverables, while the other half is dedicated to collaborative working sessions with the different stakeholders, for example working in pairs with the data engineering team on the design of our target data model or animating workshops with the product managers to define a target process.

Important to note that 50% of my objectives and key results (OKRs) are oriented towards longer-term structural projects involving planning over multiple quarters. The other 50% are focused on short-term objectives that have a quick impact, especially on smaller projects.

What’s your favorite part of the job?

My favorite part of the job is working with a diverse set of stakeholders, such as product managers, designers, data engineers, operations, sales, and even legal and finance teams. The continuous interaction with a wide range of people makes my work very interesting and engaging.

Additionally, being part of a new and growing department is very exciting as I get to witness its growth and see the impact that it has on the company.

I also enjoy the combination of technical and soft skills that are required in my role. The position requires not only a deep understanding of the product features and a strong mastery of data analysis skills but also strong communication and relational skills. This balance between technical and interpersonal skills keeps my work dynamic and challenging, which is something I really appreciate.

What’s the most exciting thing you are working on right now?

Currently, the most exciting project I'm working on is leveraging our product data for business use cases by building the appropriate dashboards for the product and customer success teams. We have a lot of product data at our disposal, and the challenge lies in leveraging it in a meaningful way. The project requires a deep understanding of the product to make sure the data we're collecting is reliable and is used in a valuable way.

We are also in the process of building a data warehouse from scratch, which is incredibly interesting. This is a strategic project that will have a positive impact on our company in the upcoming years by unlocking the full potential of our cross-department data. While it is certainly a challenging project, it's also incredibly rewarding to see the progress we're making and to know that the work we're doing will help our company in its fast growth path.

How does your current job compare with the previous jobs you’ve had?

Before my current job, I worked as a strategy and transformation consultant, where I was part of an internal consulting team in an internationally listed company. My main tasks were to conduct analyses, hold workshops, and make recommendations to improve performance and enhance efficiency. Both my current job and previous job have a common focus on problem-solving and working across different areas. However, my current job is much more product-focused, which allows me to develop deeper expertise in this area.

I work for a smaller company now, which means that I am more involved in the operational side of things, especially the execution of projects. Working in a startup environment is quite different as it is more flexible, but the expectations are higher, and things move very fast. The key to success is being a true business partner catalyzing the efforts, and offering support to move the needle forward.

The challenge here is to maintain agility and the ability to adapt quickly. Remaining hands-on and having the willingness to learn new things is essential in this environment.

What’s the best advice you can give to someone who wants to work for us?

The best advice I can give to someone who wants to join us is to stay curious. There is so much to learn, and it's important to take advantage of every opportunity to deepen your knowledge and understanding of the subjects at hand. By staying curious, you will be able to see the big picture and make more informed decisions that will ultimately contribute to the success of the company. Additionally, this mindset will help you stay motivated and engaged in your work, which is essential for professional growth and job satisfaction. So, my advice is to stay curious and continue to learn as much as you can!

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/a-guardians-portrait-dhia-productops/

April 7, 2023April 7, 2023 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