Portshift's platform was Kubernetes-native security for containerized applications.
The artifact
By April 2020, Kubernetes security had no shared vocabulary. Microsoft's Azure Security Center had just published a first attack matrix for Kubernetes, built on the same categories used in the existing ATT&CK framework for other systems, and called it preliminary. MITRE had no version of ATT&CK for containers yet; that came from Microsoft and other companies in the industry the following year. Security teams already used ATT&CK to compare every other tool they bought, but for Kubernetes there was no common language, so each vendor described its own coverage in its own terms and a buyer had no way to set two products side by side.
K8SHIELD mapped Portshift's platform onto that same structure: initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, and impact. Under each category, the framework named a specific way an attacker moves through a Kubernetes cluster and matched it to what the platform detects or blocks at that step. A compromised image pulled from an unrestricted registry falls under initial access. A publicly reachable dashboard with no service account check falls under the same category. A default Helm installation that grants administrator-level cluster access with no login required falls under lateral movement. Graboid, a cryptojacking worm identified the previous year, served as the working example for impact, the category covering data destruction and resource hijacking. The finished framework also ran as a live view inside the product, showing a customer which of these techniques applied to their own deployed clusters.
The paper came from Portshift's product side, with the product manager leading it. I came in as technical editor, working with him from the first draft through publication, mapping every technique.
The thinking
Kubernetes had reached wide production use before security teams agreed on how to talk about attacking it. Microsoft's preliminary matrix gave the market its first shared reference point, built on a structure security teams already trusted for other systems. Extending that same structure into K8SHIELD meant using categories a buyer already recognized, and introducing a new term only where Kubernetes genuinely had no equivalent in the existing vocabulary.
The harder question was how far to trust the mapping itself. A framework this specific invites a reader to check two or three techniques against the product before believing the rest of the document. Some techniques mapped to complete coverage. Others mapped to a partial defense, or to a setting the customer had to change themselves. The framework had to say which was which at every point, even where a broader claim would have read better on the page. Some of the risks it covered were already present in Kubernetes' own default configuration, active even when a customer had set everything up correctly.
Working from inside the product team, the piece had to hold two readers at once. It needed enough technical depth that a security engineer reading it line by line would find it accurate, and enough shape that someone still deciding whether to continue evaluating the product could read it straight through.
