Sure, its not always perfect, and getting say, blobless, is a challenge of its own, but no distro in their right mind for example, would ship arbitrary .o or ld.so objects in source packages.
Heck there's a few pieces of software I work on that I can't build locally, I just push WIPs to CI/CD.
I could try to setup a CI/CD pipeline of my own, but it isn't worth the time.
As a community service, the JFrog Security Research team continuously scans public repositories such as Docker Hub, NPM, and PyPI to identify malicious packages and leaked secrets. The team reports any findings to the relevant maintainers before attackers can take advantage of them. Although we encounter many secrets that are leaked in the same manner, this case was exceptional because it is difficult to overestimate the potential consequences if it had fallen into the wrong hands – one could supposedly inject malicious code into PyPI packages (imagine replacing all Python packages with malicious ones), and even to the Python language itself!
The JFrog Security Research team identified the leaked secret and immediately reported it to PyPI’s security team, who revoked the token within a mere 17 minutes!
This post will explain how we found a GitHub PAT that provided access to the entire Python infrastructure and prevented a supply chain disaster. Using this case, we will discuss the importance of (also) shifting right in secrets detection – searching for secrets in binaries and production artifacts, not just on source code.
> It seems that the original author
> - Briefly added the authorization token to their source code
> - Ran the source code (Python script), which got compiled into a .pyc binary with the auth token
> - Removed the authorization token from the source code, but didn’t clean the .pyc
> - Pushed both the clean source code and the unclean .pyc binary into the docker image
