

Last week, during the Empirical Software Engineering and Measurement (ESEM) conference, I presented the current progress of the SESAM project.
The Research Track at ESEM provides an excellent platform to showcase ongoing national and international projects that are of interest to the software engineering community. It also offers valuable opportunities to receive feedback, exchange ideas, and foster new research collaborations.

SBOMs are central to software supply‑chain transparency and are referenced by emerging regulations (e.g., U.S. EO 14028, EU CRA). Once these regulations are enforced, developers (both in open source and industrial projects) and software companies will have to deal with this new artifact, integrate it into their workflows, and share it with downstream customers. Yet little is known about SBOMs created to meet security and compliance policies in practice—as opposed to synthetic or test artifacts. Our latest work, published at the International Conference on Product-Focused Software Process Improvement (PROFES 2025), examines those policy‑driven SBOMs at scale.

Understanding automation in software security policies is one of the focal points of the SESAM project—SEcure software engineering through Sensible AutoMation.
Our team began examining how automation is configured in open-source projects on GitHub. Specifically, we looked at the effort developers put into configuring tools that serve a security purpose, such as static code analyzers. The broader goal is to compare these practices with what large software organizations do, such as Ericsson that is part of the project consortium, and to compile guidelines for sensible automation configurations—deciding when static policies are sufficient and when more dynamic, adaptive approaches might be needed.