Making security standard in Adobe Commerce

Security in Adobe Commerce didn’t become a default by accident. My part in it played out over about a decade, in a few distinct stages, and each one led into the next. Here is roughly how it happened, in order.

2015 to 2018: finding where it breaks

For a stretch of my career I spent a lot of time reporting security bugs. Between 2015 and 2018 I privately disclosed more than 35 critical vulnerabilities across Magento 1 and 2. Stored XSS, remote code execution, local file inclusion, CSRF, a couple of privilege escalations, and a few stranger ones. Most of it went through Bugcrowd, and at some point I looked up and I was ranked number 2 on their global leaderboard for Adobe Commerce. I told that story here. What it left me with was a fairly specific sense of where the platform tends to give.

2018: putting security on the exam

Finding weak spots only helps if the people building on the platform pick up the same habits. In October 2018 I went to London for the Professional Developer Plus certification workshop, and before it kicked off I pitched adding Security as a topic on the exam. The team liked it, and from the November 2018 launch onward, anyone taking that exam had to prove they could write secure code, on the frontend, the backend, and at the architecture level. Full story here.

London was the first of three times I worked on this exam. The Professional Developer Plus later became the Adobe Commerce Architect Master, and I was on the panel that wrote and revised it across all three rounds (badges on Credly). A certification isn’t something a handful of people read and forget. It’s a gate, and thousands of developers have had to get through it, which pulled up the security baseline for the custom code and extensions sitting on tens of thousands of stores.

2020: getting it into core

Getting developers to write safer code handles half of it. The other half is the moment someone finds a hole anyway and has no idea who to tell. I had been on that side of it, firing off LinkedIn messages, Twitter DMs, and emails scraped out of WHOIS to companies whose sites I had just broken, and hearing nothing back.

There was already a standard for exactly this: security.txt, later written up as RFC 9116. Building it as a Magento module and putting it on my GitHub was the easy part. Getting it into the actual core of Magento and Adobe Commerce took close to two years.

That difficulty is the whole point. Anything that ships in core lands on a huge share of the commerce world, so the bar to get it there is deliberately high, and clearing it was real work. I went through several rounds of code review and revision with Magento’s engineering team, sat in regular working meetings to walk the product owners and the community engineering group through how the module behaved, added unit tests, and had to get sign-off from a number of people on the Commerce core product team before it was cleared to ship. It was a cross-functional effort, and every iteration tightened the code until it held up to what core requires.

On 28 July 2020 it landed in the core of Magento Open Source and Adobe Commerce 2.4.0 as Magento_Securitytxt. It’s in the 2.4.0 release notes, and I wrote up the fuller story here.

Here is what clearing that bar bought. Because it ships in core, the module is inbuilt in every Adobe Commerce and Magento Open Source store running 2.4. Nothing to install, no extra dependency, and no decision for the merchant to make. Market trackers put that at somewhere between 55,000 and 80,000 live 2.4+ storefronts right now, on a platform that runs close to 20% of the top 1,000 US retailers and moves an estimated $173 billion in gross merchandise value a year. Six years and eight releases later it’s still shipping in core, maintained by Adobe in the security-package repository and documented on Experience League. That reach is the reason core is so hard to get into, and the reason the two years were worth it. The module now sits behind hundreds of thousands of merchants who have run the platform, and the millions of shoppers who hand those stores a card number and an address every day.

Now: helping pick the program

Alongside the code there’s the community side. Since 2023 I have served on the technical speaker selection panel for Meet Magento Florida, the group that reviews talk submissions and picks the technical track (my first year, and the current selection panel). After years of finding what breaks and building things to protect against it, I get a say in what the community hears from the stage.

Line it all up and it’s really one goal repeated at a bigger scale each time: make security something the platform takes care of on its own, instead of one more thing a store owner has to remember to do.