Why SCA, SAST, and SBOMs don't equal EOL planning for digital agencies
The unique business model of an agency
We’re seeing many “helpful” LinkedIn recommendations which offer to help companies achieve more secure software. What’s clear from reading them is that the business of digital agencies must be less well known outside the ecosystem than you’d imagine.
From a pure security perspective, greater exposure to security realities is a good thing - even for agencies - that is unless the initial steps needed to improve security standing is more difficult to achieve than for other IT companies.
Agencies are getting the message from their industry counterparts and from customers though: That security-first and maintenance-first delivery is fast becoming the only acceptable way of doing business in the 2020s.
Indeed, recent experience demonstrates that buyers score RFPs based on how respondents claim they secure and maintain the system in production. With an increase in agency uptake of application security tools, then the signals appear generally positive that agencies are taking note.
Just one small problem remains: Most of today’s application security tools are not actually built with agencies in mind at all.
If planning is a core part of customer-facing roles in high-performing agencies, then it follows that they either require dedicated security resource to triage and action security tool outputs or that a repeatable workflow is implemented for use by the rest of the team.
Failing in either respect is the difference between useful data and data which is actually usable.
Security platforms aren’t “security tools” in the traditional sense
Modern AppSec platforms have become best-in-class for what they were designed to do. They help security-mature companies identify and remediate risk inside individual code-bases, container images, and cloud tenancies, and they assume a familiar operating context:
A small number of internally owned products
Deeply technical users
A direct path from finding, to fixing, to deploying
For product companies, the model works exceptionally well, but for digital agencies and studios, it only partially fits.
Agencies manage project portfolios, not just individual repositories and registries
An agency’s business differs in that it operates across dozens or hundreds of client systems, where each has its own commercial contract, delivery cadence, and risk tolerance.
And for more diverse agencies, technology stacks, version control, and hosting solutions also vary markedly.
What this means is that; security data and the way it’s presented serves a broader purpose than repository or container image-specific remediation alone. It helps agencies plan client work because they’re not just beholden to the one company, but to those represented by each customer, for responsibilities including:
Budget forecasting
Maintenance planning
Feature development
Pipeline scheduling
This is why an agency-first platform does not center around individual “things” (repos, container images, etc). Rather, it positions agencies for proactive maintenance, post go-live activities and end of life software best practices, by providing an agency-wide means to aggregate end-of-life (EOL) dates, package-dependency, and security vulnerability data across entire portfolios.
Individual repositories and registries remain important, but they‘re subordinate to the questions agencies actually need answers to about their own portfolios.
Built for customer-facing roles
Agency roles at the coal-face of customer planning are not security engineers or DevOps practitioners but project managers, account managers, and executives. Each needs confidence that their insights can be reliably acted upon and confidently explained to customers.
This customer-centric context changes the environment radically. For data and findings to be useful to agencies, it should be:
Framed around actions able to be performed by traditionally non-technical roles
Suitable for proactive planning meetings and conversations, not just pull requests
Presented within design, copy, and help media which explains why not just what
Cross-portfolio visibility unlocks repeatable work
Traditional tools are designed well to answer the question: “Is this repo or image vulnerable?” leaving those skilled enough to interpret the answer to provide recommendations. But agency platforms need to be able to answer higher leverage questions:
Which customers’ apps include software due to go EOL this quarter?
Which packages implicated in supply-chain attacks impact our portfolios?
Are SSL certificate expiry dates likely to affect our customers in the next month?
What upgrade work can be grouped, scheduled, and sold proactively?
By enabling cross-portfolio search and notifications across EOL software, dependencies, and security vulnerabilities, agencies move from reactive security responses to repeatable maintenance, upgrade work, and delivery.
A strategic difference
We’ve spoken a little about less-technical users. It’s true that security and engineering-laden data minimizes the range of people able to act on it, which may further engender agency information silos. But this role-orientated positioning has more to do with context than any technical capability.
Agencies see the world through a fundamentally different lens optimized for customer-first strategic work. It must balance security, delivery, and commercial realities.
This distinction is subtle, but for agencies in the context of security tooling, it’s the difference between those which merely alert and those which enable.
Get the 1-page EOL Survival Guide for agencies to level-up your agency’s approach to end of life software best practices.
Keen to know when agency orientated security tooling finally lands? Join the waitlist and be the first to know.