Good security is decided before it's built

By Kyle Bubp, Chief Information Security Officer, Avid

Summary: Security isn't a step you do before a product launch. It's a decision you make before the first line of code. At Avid, it's a design constraint, not a checklist. Here's what that means from architecture to deployment, and how to tell which vendors actually work that way.

Security professionals have been saying “shift left” for over a decade when it comes to development, but for a long time, our industry treated security as a finishing step. You built the product, and then, somewhere between feature-complete and launch, someone ran the scans, filled in the compliance checklist, and signed it off. Security was a gate the product passed through on its way out the door.

That approach was always flawed. In today's media operations, it's dangerous.

Newsrooms and production teams no longer work inside a sealed building. Content moves between on-premises systems and the cloud, between staff and freelancers, between your facility and the field. Every connection is a surface. And media companies have become genuine targets; not hypothetically, but demonstrably.

In 2021, ransomware disrupted operations across a US broadcast group of more than 180 local stations. Two years earlier, a similar attack briefly knocked a national television network off the air. And the financial trend is moving against us: IBM's 2025 Cost of a Data Breach Report found that while breach costs declined across most industries last year, media and entertainment were among the sectors where they rose¹. The cost of a breach in our industry isn't just data. It's airtime, audience trust, and reputation.

You cannot protect that kind of operation with security that was bolted on at the end. By the time a product is finished, the important security decisions have already been made; in the architecture, in the data flows, in how systems talk to each other. If security wasn't in the room for those decisions, no amount of scanning afterward will put it there.

Designed in, not added on

This is why we build differently. At Avid, security is a design constraint, present before the first line of code.

"Security must be defined not as an afterthought but as a design principle in our products," says Ilia Murjev, product designer for security. "Everything we implement is related to established secure software design tenets."

In practice, that means every new capability starts with the uncomfortable questions. Who would want to attack this? What can they reach? If this layer fails, what does it expose? We threat-model at the design stage, when the answers can still change the architecture, not after launch, when they can only change the patch notes.

Take our approach to user credentials in Avid Content Core. The decision that the platform would never store or hold passwords wasn't a policy we added later to appease compliance auditors; it was an architectural constraint decided before a single line of authentication code was written. By forcing federated authentication from day zero, we structurally eliminated an entire class of credential-theft attack surfaces. You can't leak passwords you don't possess.

It continues through development. Every change to our codebase triggers automated security scanning, and a failure blocks deployment even to test environments. Before features ship, they're penetration-tested by external specialists asthe people who built a system are the worst people to test its assumptions.

What this looks like in Avid Content Core

Avid Content Core is the clearest expression of this philosophy because it was designed in the era when the threats were already obvious. It serves as the secure backbone for the modern, highly distributed media supply chain, ensuring that as workflows become more fragmented and content moves between more systems, security remains a constant rather than a variable. Looking at optimizing and securing your wider pipeline? We’ve broken down how in this media supply chain post.

Security in Avid Content Core is built on two principles:

• Zero Trust: No user, system, or request is trusted by default. Everything must prove itself, every time, including our own internal services talking to each other. We’ve written a whole blog post on the Zero Trust topic.
• Defense in Depth: Security controls are layered and independent, so a failure in one layer is contained rather than catastrophic.

Tenant isolation is a good example of design-first thinking. "When a tenant is provisioned in Avid Content Core, isolation is built in at the system level — data, authentication, and metadata are separated by design, and a request without valid tenant context is denied by default rather than filtered out later,” Ilia explains.

In practice, this means any request lacking valid tenant context is denied by default at the system level. A developer cannot build a new capability that "works" first and secures later; it simply won't function unless it satisfies that isolation constraint from day one. That isolation isn't a configuration setting someone has to remember to switch on. It's structural. It cannot be misconfigured away.

The same philosophy runs through the rest of our platform. The access controls protecting media on Avid NEXIS shared storage, the authenticated signal paths in our ingest and playout software solution, Avid | Stream IO, the way Media Composer connects to shared storage and asset management.

It is also why our hybrid on-premises integration requires mutual authentication by design. When connecting MediaCentral on-premises systems to Avid Content Core, we made it a strict architectural constraint that both sides must cryptographically prove their identity before a single byte of communication can even proceed. A system that connects first and authenticates later is inherently vulnerable to impersonation. We chose to eliminate that vulnerability at the blueprint stage. Different products, different jobs, one design discipline.

No platform secures itself

Security is shared. We build and operate the platform controls. Your organization configures its own identity provider, manages its own users, and decides who holds which roles. Those choices matter as much as anything we build.

Gartner² estimates that through 2026, 99% of cloud security failures will be the customer's fault, driven overwhelmingly by misconfigurations. Industry data shows that 82% of those misconfigurations trace right back to human error, not platform weakness.

We'd rather be explicit about that boundary than pretend it doesn't exist. "The more explicit, the better," as Ilia puts it. "It sets expectations very clearly and eliminates, largely, human error."

Next steps and the question to ask every vendor

Take control of your shared responsibility. Platform security is only half the battle—the configurations you manage define your actual perimeter. Download our comprehensive guide, Securing Enterprise Media Workflows, featuring Ilia Murjev’s 10-step security checklist to ensure your team is actively mitigating human error and reinforcing your defense-in-depth model.

Download the 10-Step Enterprise Security Checklist

If you're evaluating any media platform, ours included, don't ask whether it's secure. Every vendor says yes. Ask when security entered the process. Ask what gets threat-modeled, what blocks a release, who does the penetration testing, and where the vendor's responsibility ends and yours begins.

The vendors with good answers will be specific. The ones without will just tell you they “take security very seriously.”

Sources 
1. "While most industries reported a year-over-year decline in data breach costs globally, organizations in entertainment and media bucked that trend in 2025." IBM, Cost of a Data Breach Report 2025, July 2025. 
2. "Gartner projects that 99% of cloud failures through 2026 will be the customer's fault, and industry data confirms that 82% of misconfigurations stem from human error rather than provider flaws." Gartner / Exabeam Cyber Analysis, 2026.