Many teams see security as the department of no, and with good reason. Many security teams lack proper communication and people skills, falling back on “it’s policy” or “it’s a regulatory requirement” as a crutch when times get tough. This builds significant resentment between security and other teams, especially in IT and Engineering.
Working in Application Security is no different, and if anything, it’s magnified. No one likes it when you call their baby ugly, developers especially. Their presumptions, which are based on real life experiences in most cases, lead them to resent security as just another hurdle to jump through in order to meet an already tight deadline. How do you get past those presumptions? Here’s how I did it.
Before there was any discussion of security, tooling, integrations, regulations, or processes, I reached out to meet with developers on a human level. I got to know them, learned what made them tick, learned why they had issues with security in the past, and learned what pain points they had, whether security-related or not.
I extended an olive branch to get to know them as individuals, not as drones typing away to make magic happen for the powers that be. As expected, most of my emails were ignored. A few developers had great satisfaction in declining my meeting invites. However, a few were more open-minded.
The first team to reach out to me was, surprisingly, one who was vehemently against anything security-related. They had been victims of circumstance. Others had forced security policy down their throats and told them to “deal with it” when they pushed back. I went into the conversation with an open mind and, as expected, felt like I was hopping on grenades on behalf of the entire security team.
Several issues came up that were significantly hampering their ability to do their jobs. The most glaring was the approval process for open-source software.
As anyone in development knows, there’s a heavy reliance on open-source libraries. They allow developers to be more productive and focus on the custom work that actually matters for whatever they’re building. The current process required someone to review and approve each individual library. Most of the reviewers had no idea what they were looking at, relying on developers to explain the code so security could make a decision they didn’t really understand.
Nothing was stopping teams from lying to get approved. Most didn’t, but the fact that the process depended on developer honesty to function tells you everything about how broken it was.
I told them the approval process was bullshit. There’s no point running a security assessment if nobody actually understands what they’re assessing. You could see the relief on their faces. Someone from security had finally said out loud what they’d been thinking for years. I told them I’d work with security leadership to build something that would make everyone’s life easier.
I scheduled a meeting with my boss and director and walked them through why the developer teams were so reluctant to work with us. They were unaware of the prior bad experiences developers had, and how it looked from the outside like we were trying to block their efficiency and progress at every turn. I also explained how the current approval process had simply stopped scaling. We had grown from around 100 to nearly 500 people in IT and Engineering, and our team’s general lack of understanding of code and development practices only made things worse. I was also upfront about my concerns around shadow IT. Developers rely on ingenuity, and if we made things hard enough, they would find ways around our controls entirely.
To fix it, I proposed embedding the OpenSSF Scorecard directly into the CI/CD pipeline to assess libraries automatically and assign an overall score. Based on that score, one of three things would happen: auto approval, manual review, or auto reject. Think of it as the Pareto Principle applied to security reviews. Let the tooling handle the clear-cut decisions automatically and save the manual review for the edge cases that actually need a human look. Less busywork for everyone, and the reviews that did happen would actually mean something. Security leadership was surprised at how well-prepared I was for the conversation, and agreed to move forward with a pilot.
How that pilot went, and what we learned from it, is the subject of part two.