“I've learned to start balancing my technical focus and expertise with empowering my team members to develop their skills and to take the lead on certain day-to-day work.”

Twitter: @gose1

As a senior manager of security engineering at GitHub, Greg leads a team dedicated to finding and fixing vulnerabilities within GitHub's products and applications. He has a strong passion for keeping applications secure, whether through security assessment, automation and static analysis, or developer training and awareness. For more than a decade he has focused on application security, previously securing applications at CME Group, as a senior security consultant at Neohapsis, and as an adjunct professor at DePaul University teaching a graduate course on software security assessment and exploitation.

Do you believe there is a massive shortage of career cybersecurity professionals?

I do not believe that there is a massive shortage of cybersecurity professionals. However, meeting the growing needs of this industry will require us to change our pre-existing ideas about the required background and experience of individuals on a security team. Not all experienced security engineers will come with a decade of heads-down security work. The key to expanding hiring reach is to look for great engineers with a passion for security. For example, my team members spend a large part of their day performing code and architecture review, the same responsibilities one would expect of an experienced software engineer. The main difference is that our review provides a focus on security. Bridging an individual's gap of security expertise is sometimes easier than a gap in engineering experience.

The same line of thinking applies when hiring for roles requiring less experience. Many software engineering graduates are not sure what area of development will be the focus of their career. The security community needs to ensure that we make security an attractive specialty for these less experienced engineers.

What's the most important decision you've made or action you've taken related to a business risk?

Some of my most important business risk decisions were made as my company went through the rapid growth of its service offerings and technologies. Initially, when a product or engineering team comes to security with complex initiatives, it is tempting, as a security advocate, to push back and hope the rest of the company shifts in a different direction.

However, by taking a step back and looking at the overall business opportunities these new initiatives presented, I was able to help enable product goals while keeping security's concerns and recommendations intact. My team and I worked closely with engineering and product teams to identify security requirements, ensure that the decisions being made were architecturally sound from a security perspective, and see that the features were implemented in a way that kept our infrastructure and customers secure.

Looking back, I know it was imperative that I shifted my focus from being a blocker, trying to shut these initiatives down, to instead accepting the fact that our threat model and risk profile would change. I could then dedicate my team and my efforts to enabling this growth while minimizing its security impact and building security resilience into these new features.

How do you make hard decisions? Do you find yourself more often making people, process, or technology decisions?

I lead an application security team, so the difficult decisions I typically encounter involve weighing a technical security risk against the impact of changing the direction of a product feature or its timeframes. These difficult decisions typically come up when an architectural flaw leading to some security risk is identified late in the development cycle. For these situations, the risk and correct remediation are not as clear-cut as a specific vulnerability in the implementation of a service. Often, these architectural vulnerabilities can be fixed only by re-architecting or redesigning a specific feature that the engineering and product teams already have a set vision for.

In these cases, it is important to clearly and realistically state the security risk identified. It is equally important to understand the perspectives of all the teams involved and how your own view of risk differs from those of other teams. For example, a fix to a specific security issue might satisfy the need of security but at the same time may introduce a workflow that could cause user adoption to plummet or introduce significant technical debt to engineering teams. The right decision in these cases is almost never the decision that I want from a strictly security-focused point of view, but one that takes into consideration all of the viewpoints at play to ensure an outcome that strikes an acceptable balance with all of those involved. This collaboration is what has allowed me to confidently make decisions in difficult situations.

What's something that you struggle with as a leader, and how do you overcome that?

As a leader of a team of application security engineers, I constantly struggle with how I can best contribute my time to the team. I'm often tempted to spend my time digging into code or architecture reviews, contributing my technical skills toward the immediate goals of the team. I've learned to start balancing my technical focus and expertise with empowering my team members to develop their skills and to take the lead on certain day-to-day work. As the team and company have continued to grow, my shift to a strategic focus has continued, and I can rely on my team and trust them to perform solid technical work that doesn't require my oversight.

How do you lead your team to execute and get results?

Like most security teams, my team of application security engineers is greatly outnumbered by our peers in engineering. We need to continually improve the efficiency of our work to keep up with the pace of development. I push my team to identify areas where our work is redundant, is repetitive, or doesn't require our core skill set of finding and fixing vulnerabilities in our applications. In these cases, I work with the team to lay out initiatives where we can automate this work to reduce this overhead.

For example, we've invested a significant amount of development effort into automating the initial triage of submissions for our bug bounty program. With this tooling, we've been able to shift away from issuing repetitive responses to the same invalid or known low-risk reports, leaving more time to focus instead on working with the appropriate engineering teams toward a fix for valid and impactful vulnerabilities identified by the program.

This mirrors my own individual work style, looking to focus my attention and time on the most impactful work I can and limiting the time I spend on repetitive or redundant tasks.

Do you have a workforce philosophy or unique approach to talent acquisition?

When hiring members of my team, I look for experience in software engineering and a passion for security. A passion for security may be demonstrated by experience in bug bounty programs, vulnerability research, and disclosure, or by taking on a security focus within an engineering team. A successful application security engineer must be able to confidently enter technical conversations with developers and understand their goals, daily work, and requirements. A strong background in development allows members on my team to accurately assess, identify, and communicate security vulnerabilities in terms that align with engineers' daily work.

Have you created a cohesive strategy for your information security program or business unit?

To guide strategy for initiatives and priorities, I am always looking for ways that my team can most efficiently push forward our goal of reducing the risk in our applications and services. I look for new processes or tweaks to existing processes and tools we can make to increase productivity and improve collaboration with other teams.

It is important to be nimble and quickly react to changes within the company. If the usefulness of a process that worked a year ago starts declining, it is time to re-evaluate that work and see if it can be restructured to be useful in today's environment or if it should just be scrapped. This ensures that security's work naturally flows with the work of the teams that we collaborate with and that we can most efficiently make progress toward our goals.

The best way to ensure that our goals are aligned with the overall corporate strategy is to work with leadership to push the importance of security from the top down. Make sure the work your team does is known and it is known why it is important. When security awareness is instilled as part of the company culture, making progress toward reducing security risk becomes a natural and expected requirement of all initiatives.

What are your communication tips for interacting with executive leadership?

When communicating with executive leadership, it is important to be confident and decisive in your guidance. In my experience, executive leadership is looking to me as a subject-matter expert. Sometimes I'm tempted to say, “Here are all the facts, but it's not my decision to make,” but as the subject-matter expert, my guidance is my decision to make.

In security it's often hard to make decisions that don't solely reflect our adversity to technical risk. To confidently make decisions for leadership, you need to consider all of the risks a decision may introduce. Make sure you have the complete picture and details from other experts, especially from those from areas outside of security that would be impacted. If there is not enough information available to you to make a decision, dig into how to get that data. In the end, with all of the information in hand and by utilizing your own experience and expertise, you can communicate and present the best possible guidance to leadership.

How do you cultivate productive relationships with your boss, peers, direct reports, and other team members?

To cultivate productive relationships, I find it's imperative to enter all conversations and situations with empathy, leaving aside your assumptions, stress, and frustrations. I frequently am involved in potentially tense situations, either during a security incident, while discovering a vulnerability, or when trying to determine the root cause of issues. These situations are when either strong relationships can be formed or bad impressions of the security team can be made. It is important in these conversations to realize that incidents are part of the nature of security work, and it is our job to collaborate and find the best path forward.

In these situations, strive to understand why things happened from multiple perspectives. It may be the case that the product team rushed engineering timelines and efforts, maybe engineers didn't have enough training to write their code securely, or maybe it was just a fringe scenario that no amount of foresight could have prevented. By working and understanding from the viewpoint of engineers, you are able to become a strong supporting member of their team, giving them confidence to make their own security decisions and being a reliable resource when they need guidance.

This approach is equally effective when performing retrospectives with my own team members, trying to answer the question of why a security vulnerability was introduced and why we did not identify it during the development life cycle. I've learned that no security program will mitigate all the vulnerabilities, and setting this understanding with the team empowers them to do their best work. Any time we're able to dig into where things went wrong, we can use the experience not to place blame but as an opportunity to identify where we have gaps in our knowledge or processes and work toward filling them.

Have you encountered challenges collaborating with revenue-generating teams like sales and product development?

The most difficult challenge when collaborating with product and sales teams is aligning their goals of creating and selling products with security's goals of reducing risk to our customers and infrastructure. When partnering with these teams, I try to clearly communicate to them why security is important, not just to the security team but also to our customers. Customers are becoming increasingly security conscious, and strong security practices have become an attractive product feature and one way our service can stand out from the competition.

In these conversations, it is also important not to be a security absolutist. You have to realistically scope security concerns and clearly communicate their actual risk. Realize that accepting a product direction that introduces security risk might end up being the best path forward for the company and enable a product to grow and evolve. It is important in these situations to ensure that you find the middle ground that helps the product grow but also helps minimize the security concerns. This is where collaboration and creativity across multiple teams can help come up with non-obvious solutions on which product, sales, and security can confidently agree.

Have you encountered challenges collaborating with technology teams like information technology and software development?

My team collaborates most closely with software engineering teams, and we view these engineers as our customers, continually looking at how we can provide the best services that support their work. Our engineers' time and attention are our most valuable resources in securing our applications and infrastructure. So, it's critically important to make sure that our interaction with these teams is efficient and provides the best possible value. We continually look to build trust and rapport with these teams, ensuring that when they have security concerns or questions, we are their first resource.

Challenges arise in our work with engineering when we communicate without empathy, come to these conversations unprepared, or set unrealistic expectations. We must ensure we do not waste our engineering teams' time or they will not seek out our help in the future. To avoid this, it's important to understand the viewpoint, goals, previous security discussions with the team, and existing architecture decisions. We asynchronously collect all the information possible to get up to speed on their work and can enter these conversations the same way a peer on their team would.

In these conversations, it is important to establish that the security of their work is a collaborative effort and we are available as experts whenever they have concerns. My team's goal is to allow engineers to ship their applications and services with confidence in their security posture. When issues do occur, we will be working with the same team during an incident, and establishing this collaborative relationship helps us to efficiently handle and mitigate security issues as they arise.

In the end, to be successful, we must be viewed as a useful and important partner of engineering teams. If we are viewed as an adversary, a hindrance to their progress, or just a checkbox that provides no value, we cannot effectively collaborate to meet our security goals.