How to be an engineer that security people don't hate
Be collaborative but firm!
In a past newsletter, I wrote about how to be a security person that engineers don’t hate, inspired by these two articles, “How to be a PM that engineers don’t hate” and “How to be an engineer that PMs don’t hate.” In this newsletter, I write the other side: being an engineer that security people don’t hate.
As an engineer, especially in an organization that has an operationally focused security team, it’s important to reduce friction between the two groups because it ultimately saves you time. You can actually help reduce risk rather than wasting all your time fighting with security. Here’s how to be a good partner to security:
Collaborate on incorporating security issues into engineering processes
Don’t be an intellectual bully (don’t mistake technical knowledge for intelligence)
Share context
Compromise on solutions
Be empathetic
This is a start. There are definitely more ways, but it’s important to be a good partner even though sometimes security teams can be tough partners.
Collaborate on incorporating security issues into the engineering processes
I agree that security alerts can be noisy, and many times, they do lack context. However, in that mix, there are a series of useful alerts. Sometimes, an engineering team has lost track of a package, and it’s at end-of-life. Or, a team has ignored updating a package after realizing there’s a breaking change, but now you’re several breaking changes behind and just one critical security update away from a major incident. The list goes on.
Unfortunately, it’s frustrating because many security teams don’t put in the work to provide the proper context on alerts, such as vulnerabilities. Many times, these alerts are “dumped” onto engineering, but sometimes, security teams don’t have the visibility or aren’t enabled to provide the necessary context. Although it’s easy to blame this on security, it’s still worthwhile to expend energy to find a solution rather than just complain. For example, an engineer could work with an application security engineer to create a template on how to upgrade certain packages that don’t have breaking changes. Similarly, an engineer can help the security person create automation to only create PRs for vulnerabilities of a certain maturity level. This way, these PRs and tickets can be resourced and done during sprints.
There are a lot of simple processes an engineer can help a security person build so that it can help cut through the noise. In fact, the lack of processes to handle vulnerabilities could reveal problems in the engineering processes, such as insufficient resources to pay down tech debt. On the other hand, engineers can help frame certain security issues as tech debt and work with security to foil them into existing processes.
Don’t be an intellectual bully (don’t mistake technical knowledge for intelligence)
This is pretty straightforward. You’re both on the same team, so don’t be an asshole. Security likely doesn’t have the same technical skills as you do, such as software development skills. However, they tend to have a high cognitive load since they typically are responsible for the security of the whole organization. They are forced to learn fast, adapt to changing threat landscapes, and learn new technologies at the same time. Any lapse in understanding could lead to a security incident.
No skillset is superior. Each skill set serves different purposes/values to the company. For example, especially in regulated spaces, security shields engineering from a lot of complicated compliance work.
Share context
Many times, security is separate from engineering (I believe this is a problem, and I’ve already written extensively about this). They have different visibility and sometimes different OKRs. As a result, the contexts each team has is inevitably going to be different. When you can’t do something for security, you should share context on why this risk is not as great as you think because you’re potentially dealing with issues that have higher business risk/implications.
When security believes something is simple but it’s not, you should share context on the confounding factors that might make a seemingly simple fix much harder than they seem. These types of contexts will make conversations easier because each side won’t feel that they are dismissing each other’s needs.
Compromise on solutions
It’s easy for each side to come off as decision-makers, who “need” something done. Ultimately, remember you’re both on the same team. It’s important to come up with solutions. Of course, with these solutions, neither side will be happy, but hopefully, they will create scalable processes that benefit both sides and the company in the end. It’s common that many security issues are a result of tech debt. I think it’s impossible to clean up all of the tech debt, and in a vast majority of companies, there will be more problems than the teams have the resources to solve. Rather than saying no, you can compromise on a solution with security. For example, you agree to do a task but only if they come up with a more predictable workstream in the future. Especially, with compliance and security operations-related tasks like pentests, there could be surprise work, which can be frustrating for both sides to manage. You can work together to figure out how to make this type of work more predictable and efficient in the future.
Be empathetic
This is generally a good life tip, but at many organizations, unfortunately, the executive team sees security as a tax that they want to minimize rather than a value adder. Many things create this dynamic, including poor technical leadership in both security and engineering. However, the security team has to deal with the consequences, so many times, they are forced to behave in certain ways. For example, I’ve heard some security leaders tell their employees to purposefully fight against engineering whenever there’s pushback so that they can stay relevant. Some organizations have leaders who spend more time on social media complaining about the state of their organization and security as a whole rather than managing their teams.
Unfortunately, unlike engineering, it’s more likely that security is viewed as a blocker or a must-have, and as a result, they are given few resources to accomplish a lot. When security incidents happen, the executive team treats them as a scapegoat. In no way do I believe this is productive, but it’s a reality in many companies. Engineering receives a lot more leeway than security, so you should recognize that and use that to do good.
Security is trying to do the best with what they have, and it’s a thankless job. If nothing happens, people rarely thank security, but when bad things happen, security not only has to take the brunt of the work but also the blame.
Takeaway
Engineering typically wields substantial power and influence in an organization because of its ability to scale. It’s important to recognize this and use it to have a productive relationship. This involves sharing context and having an open line of communication where both sides can understand and align with each other’s goals. Engineering can also reduce a lot of friction because they have the technical ability to create a lot of scalable processes and platforms. Just remember both of you are on the same team and ultimately want the same outcome.