From Salesforce Breaches to IRAP Reality

The last 18 months have seen too many Salesforce breaches — Qantas, Google Ads data, Allianz, LVMH brands — none of these have been traced back to exotic zero-days, but to basic access control failures and environments where development and support teams have had far too much reach.

In a DevSecOps culture, “developer everywhere” is not a badge of trust. It’s a liability multiplier. Every non-dev environment — from SIT to UAT to staging to pre-prod — is a step closer to production risk. If you let developers roam freely there “to debug faster”, you’ve just bypassed the most important security controls IRAP, FedRAMP, and SOC 2 expect you to have.

Why Access Control Is Your First Defence

IRAP at Protected level and above assumes hostile actors may already be in your network, this assumption is the gold standard Every environment with customer data (even masked) is subject to the same sovereignty and audit expectations as prod. If a developer has no business reason to be there, they should not be there.

• Prod and near-prod: No dev access. Period. Debug via logs, replicas, or approved incident windows.
• SIT/UAT: Access via controlled service accounts, not personal credentials.
• Security-sensitive repos: No intra-team PR approvals for cyber-facing code. Require cross-team or security-cleared reviewers.

Separation of Duties: The Non-Negotiables

• No self-approval of PRs — including “one-liner fixes” and “emergencies”.
• No PR approval within the same delivery team for internet-facing or cyber-critical components.
• Release gates that require sign-off from Security/QA before merge to mainline.
• Immutable pipelines — if you can edit the pipeline to bypass tests, you’ve already failed IRAP control objectives.

Automated Testing: The Baseline, Not the Finish Line

Tools like Copado Robotic Testing (CRT) and DigitSec SAST/DAST aren’t “nice to have” — they’re the entry ticket. They catch the first layer of defects: regressions, obvious security issues, functional mismatches. But they do not replace human testing.

• Automated tests to catch what’s obvious - its your saftey net
• Human exploratory testing = spotlight to find what the net misses and edge cases.
• Security testing must be repeated after every major code change, not just before “big bang” releases.

Environments Must Be Disposable

IRAP assessors will ask: “If this environment was compromised, how would you recover?” If your answer isn’t “destroy and redeploy from code + config + seed data in under 4 hours”, you’re not compliant with the intent.

• No production data in non-prod. Ever. Use synthetic, production-like data sets.
• Automated environment rebuild scripts that run cleanly without human tweaking.
• Repeatable test loads so automated tests can run the same way, every time, from scratch.

The Release Manager’s Real Job

Finally, your Release Manager is not there to “help you get into prod faster”. They are there to stop you cutting corners. Their accountability is to the CTO and the Board, not to the dev or project team, no matter how much you want them to be!

In governance terms, every forced release that bypasses controls increases director liability. If a rushed change exposes customer data or breaches IRAP controls, it’s not just a bad day for DevOps — it’s potential prosecution

So the next time you’re tempted to push that “just a quick fix” through without approvals, remember: the Release Manager’s “No” is the Board’s firewall. If you can’t convince them, you shouldn’t be shipping it.

Security is Not Your Velocity Enemy

Locking down environments, enforcing separation of duties, and investing in disposable infrastructure doesn’t slow you down — it stops you from slamming into a wall. The Salesforce breach headlines aren’t “security team’s fault” — they’re DevSecOps failures where speed was prioritised over discipline.

IRAP, FedRAMP, SOC2 — they’re not asking you to be perfect. They’re asking you to be deliberate. And that starts with removing the “developer everywhere” anti-pattern from your culture, today.

Don’t wait for a breach to discover your governance gaps. We can audit your release process against IRAP, FedRAMP, and SOC2 — and give you a risk-based action plan to lock it down without killing velocity. Schedule a DevSecOps Release Audit with AppGenie

• Back to Blog