惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

The Hacker News
The Hacker News
D
Docker
GbyAI
GbyAI
Y
Y Combinator Blog
C
Check Point Blog
M
MIT News - Artificial intelligence
Martin Fowler
Martin Fowler
D
Darknet – Hacking Tools, Hacker News & Cyber Security
Blog — PlanetScale
Blog — PlanetScale
P
Palo Alto Networks Blog
Recent Commits to openclaw:main
Recent Commits to openclaw:main
V
Vulnerabilities – Threatpost
I
InfoQ
Simon Willison's Weblog
Simon Willison's Weblog
博客园_首页
T
Threat Research - Cisco Blogs
J
Java Code Geeks
Hacker News - Newest:
Hacker News - Newest: "LLM"
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
The Register - Security
The Register - Security
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
阮一峰的网络日志
阮一峰的网络日志
O
OpenAI News
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Recent Announcements
Recent Announcements
Forbes - Security
Forbes - Security
AWS News Blog
AWS News Blog
雷峰网
雷峰网
博客园 - 三生石上(FineUI控件)
S
Security Affairs
H
Heimdal Security Blog
Engineering at Meta
Engineering at Meta
T
Troy Hunt's Blog
T
Tenable Blog
MongoDB | Blog
MongoDB | Blog
H
Hacker News: Front Page
IT之家
IT之家
N
News and Events Feed by Topic
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
G
GRAHAM CLULEY
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
V
Visual Studio Blog
S
Secure Thoughts
U
Unit 42
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
The Last Watchdog
The Last Watchdog
S
Security @ Cisco Blogs
NISL@THU
NISL@THU
T
The Blog of Author Tim Ferriss

Railway Blog

Where Railway is, and where it's going (Summer 2026) PaaS vs IaaS vs SaaS: What Each Means and Who Should Pick What in 2026 The Best Continuous Deployment Tools in 2026 The Best PaaS for Multi-Region Deployments in 2026 The Best Platforms for Monorepo Deployments in 2026 What is BYOC (Bring Your Own Cloud)? A Developer's Guide for 2026 The Best Managed Kubernetes Hosting in 2026 The Best Container Registries in 2026 The Vanilla Cloud Tax: What Rolling Your Own on AWS Actually Costs What is a PaaS? A Developer's Guide for 2026 The Best Cloud Observability and Logging Tools in 2026 The Best PostgreSQL Hosting for Developers in 2026 The Best Multi-Region Hosting Platforms in 2026 The Best Platforms to Deploy AI Apps in 2026 (Not the Models, the Apps Around Them) The Agent-Native Cloud: What It Means and Why It Matters Incident Report: May 19, 2026- GCP Account Suspension Counting to 3 with a new builder processing 50M+ monthly builds Railway iOS preview now available via TestFlight Kill your onboarding: selling to 10,000+ new users a day Your AI wants to nuke your database. Guardrails fix that. Better Rails for Agents: A New Remote MCP and Railway Agent in the CLI Moving Railway's Frontend Off Next.js One command deploys, there's a Stripe APP for that From registrar to deployed: buying a domain inside Railway A letter to open source builders who deserve more Networking is a black box, we used eBPF to open it Heroku Walked So Railway Can Run Security Features Your Security Team Will Love Railway Runs Open Source, Now We're Funding It Railway raises $100M Series B to unburden the builders Deploy autoscaling services, AI Workflow automation, and LLM APIs Without Kubernetes Hosting Postgres with GeoLite2: a practical guide to IP geolocation, data loading, and updates Serverless functions vs containers: CI/CD, database connections, cron jobs, and long-running tasks Hosting Postgres with pgvector: provider tradeoffs, migrations, indexes, and tuning Introducing the Railway integration on Delve.co Secure Cloud Hosting for Compliance: A Practical Guide for Startups and Regulated Industries How G2X Unlocked Rapid Experimentation at Scale with Railway MindFort Runs 100+ AI Pen Testing Agents Without Their Previous $10k AWS Bill How Bilt's Marketing Engineering Team Delivers at Scale with Railway Railway Technology Partners: Earn Revenue on Templates You Didn't Build ~$1 Million Paid to Developers Who Built Railway Templates CI/CD for Modern Deployment: From Manual Deploys to PR Environments Kernel Powers 1,000+ AI Agents on $444/Month of Railway Infrastructure Deploy Full-Stack TypeScript Apps: Architectures, Execution Models, and Deployment Choices Railway vs Cloudflare: How Their Architectures Differ and When to Use Each Run Scheduled and Recurring Tasks with Cron Monitoring & Observability: Using Logs, Metrics, Traces, and Alerts to Understand System Failures Logs, Metrics, and Traces: What Does Each Signal Tell You? Server rendering benchmarks: Railway vs Cloudflare vs Vercel Top five Heroku alternatives Comparing top PaaS and deployment providers Pricing to Encourage Use The F in SOC2 stands for functional Deploy Together, Earn Together: Introducing Railway Partnerships How We Oops-Proofed Infrastructure Deletion on Railway Bring Back the Free Plan Railway MCP - Stateful, Serverful, Pay-per-use Infrastructure Hackathon: Winners Announced! Mark Your Calendar: Railway User Hackathon with Prizes Launching Railway's Affiliate Program Zero-Touch Bare Metal at Scale Ssh, We’re Announcing One More Thing! $1M for Open Source Introducing Central Station Speed Isn’t Just About Code, It’s About Where That Code Runs One-Second Deploys? We Didn’t Believe It Either Why We’re Moving on From Nix Railway V3: Faster and Cheaper How to Migrate from Cloudflare Pages to Railway Supercharging Directus on Railway with a Static Frontend How to Migrate from AWS Lambda to Railway Deploy Triton Inference Server on Railway How to Handle Database Connection Pooling Building a NestJS App on Railway Manually Optimize Deployments on Railway Implement a GitHub Actions Testing Suite Scaling a SaaS application on Railway Building a SaaS application on Railway Deploy a Dart App on Railway, Part 2 Deploy a Dart App on Railway, Part 1 Implementing Feature Flags from Scratch Cron Jobs with Django and GitHub Actions Deploy Offen on Railway Queues on Railway Working with NX, Railway and CI/CD Automated PostgreSQL Backups Using GitLab CI/CD with Railway Migrating From Heroku To Railway Cron Jobs on Railway Deploy Beam on Railway Deploy Authorizer on Railway Deploying Monorepo Applications How to Backup and Restore Your Postgres Database How to Backup Your Redis Instance Deploy Cusdis on Railway Deploy Ghost on Railway Using Github Actions with Railway Deploy Calendso (cal.com) on Railway Self-hosted website analytics Use Notion as a CMS for your NextJS blog
Compliance Isn't a Feature, It's a Posture
Angelo Saraceno · 2026-05-26 · via Railway Blog

Avatar of Angelo Saraceno

Angelo Saraceno

A SOC 2 Type 2 attestation tells you what a vendor was doing for the twelve months ending on a specific date. It does not tell you what they're doing now. If you bought based on the badge, you bought yesterday's vendor, and yesterday's vendor is not the one operating your production environment.

Before Railway I was at Citrix, where I spent a meaningful chunk of my career on customer environments at Verizon and Lockheed Martin, the kinds of places where the procurement team treats a security questionnaire as a load-bearing artifact and where "compliance" is a department with a budget. I have watched the compliance industry from both sides of the table: the vendor side, watching engineers reshape their work to satisfy an auditor's checklist, and the customer side, watching procurement teams accept a PDF as a substitute for trust.

What I have learned, across both sides, is that compliance is not a feature. It is a posture. It is the difference between a vendor who can produce an attestation because their daily operating discipline happens to satisfy the controls, and a vendor who can produce an attestation because they spent the last quarter retrofitting evidence for a Type 2 window. Both vendors will hand you the same PDF. Only one of them is safe to buy from. This is about how to tell which is which, and why the question matters more every year that the auditing industry commoditizes the badge.

The checkbox compliance problem

The compliance industry has, over the last decade, achieved something impressive: it has turned a discipline that used to require taste into a procurement artifact that can be ordered from a vendor portal. Vanta, Drata, Secureframe, and the long tail of GRC tooling have done for SOC 2 what Stripe did for payments. The friction is gone. The expertise is automated. The output is a PDF.

This is, on balance, a good thing. A startup with five engineers can now achieve a SOC 2 Type 2 in months, not years, and the controls it implements along the way are mostly the controls it should have implemented anyway. The floor has risen. The problem is what happened to the ceiling.

When a credential is cheap to acquire, it stops carrying information. SOC 2 used to mean "this vendor takes security seriously enough to spend a year and a quarter-million dollars on an audit." Now it means "this vendor spent eight weeks and forty grand on a guided GRC workflow." The badge is the same. The signal underneath it is not.

Buyers have not caught up. The procurement playbook still treats SOC 2 Type 2 as a meaningful filter. The questionnaire still asks the same questions it asked in 2018. The answers are still graded on a pass/fail basis, with no follow-up on whether the controls described in the attestation reflect how the vendor operates on a Tuesday afternoon when an engineer is on call and a customer is reporting a strange behavior. The result is that compliance has become a feature: a thing the vendor ships, the buyer consumes, and neither party thinks about again until renewal.

I wrote a piece last year called "The F in SOC2 Stands for Functional," which argued that the auditing industry has incentives to commoditize attestation. That piece was about the supply side. This one is about the demand side. Buyers are not powerless. The compliance industry has shaped itself to what buyers ask for. If buyers ask for badges, vendors will ship badges. If buyers ask for posture, vendors will have to demonstrate posture, and the ones who cannot will reveal themselves.

Posture, defined

Posture is the set of operational disciplines a vendor practices when no auditor is watching. It is the default behavior of the system and the default behavior of the people running it. It is, by definition, the thing that an annual attestation cannot measure, because the attestation is a snapshot and posture is a continuous quality.

There are four disciplines I look for, and they generalize across nearly every vendor category.

The first is continuous monitoring. A SOC 2 Type 2 audit measures controls over a twelve-month window. A vendor with good posture measures their controls every minute. They have alerting on access patterns, on configuration drift, on dependency vulnerabilities. They do not wait for an auditor to ask "how do you know your encryption-in-transit is still on?" They know because the system is checking, and because a human is paged when the answer changes.

The second is defensive defaults. The single highest-leverage security decision a platform makes is what behavior it ships with the checkbox already ticked. If encryption-in-transit requires an opt-in, most customers will not opt in. If audit logging on admin actions is a paid feature, most customers will not pay. A vendor with good posture treats the secure configuration as the default configuration, and treats every deviation from the default as an explicit, logged, reversible decision. The opposite vendor ships a permissive default, points to the documentation, and treats customer misconfiguration as a customer problem.

The third is incident response history. Every vendor has incidents. The difference between a vendor with posture and a vendor with marketing is what happens in the seventy-two hours after the incident resolves. Does the vendor publish a postmortem? Does the postmortem name the root cause, the contributing factors, the action items, and the people who own them? Or does the status page get a vague update and a "we apologize for the inconvenience"? Public postmortems are the most legible signal of operational seriousness, because they require the engineering team to commit, in writing, to a version of events they cannot quietly revise.

The fourth is engineer ownership. In organizations where compliance is a feature, security is a department. Engineers ship code, the security team reviews it at the end of the process, and the compliance team writes the evidence. In organizations where compliance is a posture, security is a shared concern. Engineers think about threat models when they design APIs. Code review includes a "what does an attacker do with this" question. The compliance team exists to coordinate, not to absolve. You can tell which kind of organization you are dealing with by asking an engineer at the vendor a security question and watching whether they answer it or redirect you.

Evaluating a vendor's posture

At a glance:

Comparison of good versus weak vendor posture across postmortems, logging, encryption, who answers, and secrets scoping
Comparison of good versus weak vendor posture across postmortems, logging, encryption, who answers, and secrets scoping

The procurement questionnaire will not tell you any of this. The procurement questionnaire is a hashing function: it reduces the vendor's posture to a series of yes/no answers, and the vendor's GRC tooling has been optimized to produce yeses. You will need to ask different questions.

Ask where the most recent incidents are documented. Not "have you had incidents," because every vendor has. Ask for the URL of the most recent public postmortem. A vendor with good posture will send you a link in under a minute. A vendor with bad posture will route the question to legal.

Ask what the platform's defaults are. Are admin actions logged by default, or is audit logging a feature flag? Is encryption-in-transit on by default, or is it a configuration the customer applies? Are secrets scoped per-environment by default, or does the platform encourage a single shared bag of environment variables? Defaults are revealed preference. They tell you what the vendor believes the median customer should be doing.

Ask who answers your security questions during procurement. If your security questions are routed to a sales development representative reading from a knowledge base, the vendor has built a process to insulate engineers from buyer scrutiny. If your questions are routed to a security engineer, or to the CTO, the vendor has decided that buyer scrutiny is a thing engineers should participate in. Both are choices. Only one of them produces accurate answers.

Ask whether the platform publishes security-relevant release notes. A vendor with good posture will tell you, in a changelog entry, when they ship a control improvement: a new audit log field, a tightened default, a deprecated authentication mechanism. A vendor with bad posture will treat security changes as silent, on the theory that publicizing them implies prior weakness. The first vendor is operating from a position of confidence. The second is operating from a position of marketing.

If a vendor cannot answer these four questions in writing, in a single email thread, with concrete URLs and not vague gestures at "our security page," the SOC 2 PDF in your folder is decorative. It is not evidence of posture. It is evidence that the vendor knew how to hire a GRC consultant.

The Railway posture

I work at Railway, so I will be brief and honest. The point of this section is not to pitch the platform. The point is to show what posture looks like when you describe it concretely, so that you can apply the same lens to any vendor.

Railway scopes secrets per-environment by default. Production, staging, and ephemeral PR environments each have their own isolated variable store, and promoting a service across environments requires an explicit action, not an accidental copy. Encryption in transit is on by default for every service, both for ingress and for private networking between services in the same project. Admin actions, including environment variable changes, service deletions, and permission grants, are recorded in an audit log that workspace owners can review. We publish postmortems on our public status page when incidents have customer impact, and we describe the root cause in enough detail that a reader can form their own opinion about whether we have done the work. Security-relevant changes are called out in our changelog when we ship them.

None of this is exotic. All of it is the kind of thing a vendor with good posture should be able to describe in five sentences. If your current vendor cannot, that is the signal.

Closing

The compliance industry will not change. The incentives are too aligned: auditors want repeat engagements, GRC vendors want recurring revenue, and the vendors who buy GRC tooling want the smallest possible distance between "we exist" and "we have a SOC 2." The badge will continue to get cheaper. The signal underneath it will continue to weaken. None of this is going to be reformed by a regulator or a standards body.

What can change is how buyers evaluate. The next time a vendor sends you a SOC 2 Type 2 report, read the date on it, then ask them what they have shipped since. Ask for the most recent postmortem. Ask what the defaults are. Ask whether an engineer or a salesperson is answering you. The vendors who treat compliance as a posture will recognize the questions, because their daily work is the answer. The vendors who treat compliance as a feature will hand you the PDF a second time and hope you stop asking.

Buy from the first kind. The badge is the floor. Posture is the building.

Happy shipping.

Angelo


Angelo Saraceno is a Solutions Engineer at Railway. Before Railway he was at Citrix, working inside Verizon and Lockheed environments, so he has seen what "enterprise IaaS" looks like after the slides come down. He writes about infrastructure, deployment, and the gap between how cloud is sold and how it runs in practice.

Try Railway →