Let’s start with a few numbers: SAP S/4HANA contains more than 300 million lines of code, the software runs more than 90% of the world’s largest corporations and, most importantly for the scope of this article, it currently keeps about 10.000 developers at SAP busy. Those developers are spread all over the globe, covering pretty much every time zone. In this challenging setup, how do you ensure the secure delivery of software? Short answer: transparency. Long answer: continue reading.
Obviously, the answer is more complex than that. In order to ensure the security of a software that complex with that many developers in a decentralized setup, quite a few measures have to be in place in order to ensure securely written code and applications. These issues are addressed by SAP, as we have implemented a „shift-Left“ approach to security early on, including a product standard for security, a secure development and operations lifecycle (we need to secure our cloud environments, too), and, of course various tools and trainings to support developers in developing secure code in the first place.
Nevertheless, with 10.000 people working on the code daily, overseeing the security posture of the written code can be challenging, to say the least. This is why we have come up with the „Security Execution Dashboard“. At this point, we have to make a confession: there’s not much new stuff in the dashboard – but as with a lot of good things, it’s the combination of existing features and functions that make the dashboard so powerful – and is one of the reasons it won the prestigious CSO50 award this year, making it the second year in a row that SAP was able to win this particular award. Let’s deep dive into what made the security execution dashboard award-winning.
One of the biggest technical hurdles was the sheer diversity of tools involved. SAP’s security landscape includes a mix of industry-standard scanners like GitHub, Blackduck, and Checkmarx, as well as SAP’s own tools like FioriDAST. Each of these tools speaks its own language—different data formats, different APIs, different update cycles. To make sense of this chaos, the team built a unified data extraction framework. Think of it as a translator that sits between the dashboard and each tool, standardizing the way data is pulled, parsed, and processed. Every tool got its own connector or adapter, ensuring that no matter how the data looked coming in, it would be clean and consistent going out.
But pulling the data was only half the battle. The next challenge was making it meaningful. Security data is only useful if it’s tied to the right team, the right product, and the right release. That meant building a harmonized data model that could map scan results to specific areas of responsibility. This wasn’t just a matter of matching names—it required defining mapping rules, building validation mechanisms, and ensuring that the same issue wasn’t counted twice or missed entirely. The result is a dashboard that doesn’t just show you what’s wrong—it shows you who needs to fix it.
Performance was another sticking point. Querying live data from all these tools in real time would have brought the system to its knees. So the team implemented caching and temporary in-memory storage to keep things fast and responsive. Frequently accessed data is now stored locally, reducing the load on source systems and ensuring that developers aren’t left waiting for their dashboards to load.
Data quality also proved to be a recurring issue. In the early days, scan results were often misattributed or incomplete, making it hard to trust the insights. To fix this, the team introduced a robust data quality management process. Automated validation checks, regular audits, and feedback loops with tool owners helped tighten the accuracy of the data and improve the reliability of team mappings.
And then there was the human side. Convincing thousands of developers to adopt a new tool—especially one that shines a light on security gaps—is no small feat. The team tackled this with a mix of early engagement, pilot programs, and a strong internal communications push. Over time, the dashboard earned its place as the go-to source for security insights, not by mandate, but by proving its value.
Today, the Security Execution Dashboard is more than just a reporting tool. It’s a living system that adapts to the needs of SAP’s engineering teams. It’s fast, it’s accurate, and it’s deeply integrated into the way SAP builds software. And most importantly, it’s helped shift the conversation around security—from something that happens after the fact, to something that’s embedded from the very first line of code.
Bluesky
