How many times have you handed off a test report, or performed a test readout, to have developers say, "eh, we'll fix it when we get a chance" and then it goes unfixed for months? How do we get into their heads and help them modify their software development life cycle to take security into account?

Developing a product security group (or application security group, AppSec) is not an easy process that can be solved with tooling alone. The technical aspects will likely remain the same from company to company, however, the people and business processes do not. Developers are busy writing functional code and can't take the time from developing for their minimally viable product (MVP) to fix normal bugs. Formulas for success should incorporate styles that will win the hearts and minds of your developers. My experience is that friendly chats, camaraderie, empathy, commiseration, and bribery (yes, bribery) work well.

Companies which have a fledgling application security program might experience these symptoms:

• Most of the developers want to do the right thing (but aren't enabled to do so)
• Stakeholders need an minimally viable product (MVP) right away; security can wait (we need customers!)
• Product owners won't prioritize security features (although these are getting easier to implement)
• Security vulnerabilities are deprioritized and sit in the backlog, adding to technical debt

The Search for Purpose

As a small part of our large company, we get wrapped up in our work and sometimes lose focus on why our company exists. This is sometimes difficult to believe, but companies have one purpose -- to generate revenue. Who are we to get in the way of generating revenue? We all need to be on the level and be honest with each other: The purpose of the AppSec team is to help the company guarantee that the software they create allows them to continue being profitable. What does that mean? This means, as advisors, we need to help developers identify security issues early in their development process, through architecture reviews and training. Throughout the development process, we need to help them ensure the application fits the confidentiality, integrity, and availability requirements: Does the data need to be protected? Can we be sure the data hasn't been tampered with? Are we meeting the company's availability targets by avoiding performance problems?

That's great. I think I'd be able to do this if I were in the shoes of the engineering director, but how can I be successful in an advisory role?

Developers, Engineers, and SREs are your friends

This is the most impotant part of this job to understand. If you don't read anything else in this article, this should be the section you take away. A program cannot be successful if you're viewed as an adversary towards developers and their teams. This concept seems obvious at first glance, and once you've participated in a product team's Sprint Review / demo and see what their product does, you'll see that developers are where the solutions start and where the problems end. In your first weeks in the role of an AppSec Engineer, make an effort to meet with several team leads to get an understanding of how the company operates. If you've moved into a product security position from within your company, your developer peers might already know you.

The last thing most of us like to do is sit in meeting after meeting, but we all need to eat and drink at some point, right? Get together for beverage of choice, or a meal, and chat about common interests, like the latest version of Angular or React, games, dogs, etc. Keep this as a one-on-one meeting. Introduce yourself as you would meet someone else that's outside your company. It's important to note the tone of this meeting is informal, but you should get to learn as much as you can from this person. Do the same thing with others across different product lines and teams. You should start to build rapport with these people, as you will be working with them on a fairly regular basis as part of your job. Glean as much information about the people they work with so you can build out your portfolio of individuals that you can lean on for information.

Towards the end of your meeting, ask them what bothers them most about security, and listen.

Product Owners and Stakeholders can be your friends, too

In the same vein as working with developers, engineers, and SREs, we need to be on the best terms with the product owners and product stakeholders. Treat them in the same fashion with the initial meeting with our peers.

In most cases, the stakeholder is typically the person (or people) who are driving the requirements of the product. The product owner (PO) is typically the person in charge of making sure the right work is getting done in the proper order, among other important tasks. If the development team is using Scrum, you can also meet with their scrum master.

The product owner is responsible for satisfying the requirements put forth by the stakeholder. In most cases, a product owner will ask their team to prioritize all of the user stories to satisfy the stakeholder, and will typically de-prioritize bug fixees unless they're blockers during the MVP phase of rolling out a product. What sometimes happens is these bugs end up polluting the backlog well past the MVP and will probably be ignored, adding to the team's technical debt. It's important that the product owner and stakeholders understand that new security assessments, pen tests, automated code scans, and integration of security tools into the CI/CD pipeline (DevSecOps), you'll be adding to their backlog of security items to fix on a constant basis.

POs and Stakeholders are the ones to give you the most pushback. If you don't experience any pushback it's likely they're just ignoring you. You will affect their timeline when you find high risk issues, so make sure you negotiate a remediation schedule with them, and engage with your manager at the same time. This way, you can come to an agreement that makes sense for everyone, and you can focus on helping the engineers find a good solution for remediation.

Conclusion

These are two approaches to helping you become successful in an AppSec program. If you find these tips to be helpful, or if you have tips of your own, please leave a comment below!