OP here. Sharing this early because I'm trying to gauge if this specific pain point is widespread, or if I'm just scratching a niche itch.
Context: I’ve been working in a regulated monorepo and realized that almost all existing supply chain tools assume you are a large enterprise with dedicated infrastructure.
The gap I found:
Scanners are reactive (they yell at you after the fact).
Artifactory/Nix are heavy (they require rebuilding your workflow or hosting servers).
I wanted something in the middle. The idea is a lightweight CLI that acts as a local proxy to gate npm/cargo/go requests against policies stored directly in git. It forces "lockfile intent" (what the dev wants) to match "security policy" (what the repo allows) before the package hits the host.
The mechanism I'm most interested in feedback on is the enforcement logic: sbom check --policy-from=origin/main
This allows the CLI to judge the "crimes" on your feature branch against the "laws" defined in main. It effectively prevents a developer from un-banning a vulnerable package in the same PR that introduces it.
Does this "local proxy" approach feel like the right middle ground to you, or is the overhead of a proxy too much for a daily driver?
I can question the qualifications of a person as it relates to a specific position (e.g. CEO), but that doesn't mean I don't respect their past contributions.
I find the accusations of sexism towards anyone who dares question her as excessive as some of the comments that were made towards her.
The accusations aren't "towards anyone who dares question her", they're towards people who assume that she had come in after the fact and unfairly got into somebody else's role, which is ignorant (and easily cleared up by glancing at a Wikipedia article) and also a common refrain aimed at any woman in any position of authority.
I'm not a fan of Baker for many reasons, but "how did she even get that role?" always pings my shithead radar, and isn't a question I hear for incompetent male CEOs, who are assumed to be just incompetent, while the women are assumed to be incompetent infiltrators who were hired on the basis of their sex.
> I can question the qualifications of a person as it relates to a specific position
Sure, but do people generally question the qualifications of founders that successfully grew something from inception? Or is it only for people who are women? Because I definitely see a trend in the comment threads in HN over the last many years.
Founders don’t face any competition when they get the job at their own companies, and they often have ownership to force it as an outcome if there’s ever a debate.
Baker, to her credit, probably faced brutal competition to get to the top job. It’s not out there to wonder why she was picked, and the answer cannot be because « she was there from the beginning ».
HN tends to like people who have a certain understanding of product and technology. Baker’s legal background probably didn’t help put forward her other skills, hence the questions.
If the argument is based on trends your personally noticed on HN, then I’m afraid there’s not much to discuss.
> Baker, to her credit, probably faced brutal competition to get to the top job. It’s not out there to wonder why she was picked, and the answer cannot be because « she was there from the beginning ».
Baker was Mozilla Foundation's president from founding to 2025. She was Mozilla Corporation's CEO from founding to 2008, interim CEO from 2019 to 2020, and CEO from 2020 to 2024.
You think there was brutal competition for Mozilla Corporation CEO in 2020?
> Baker, to her credit, probably faced brutal competition to get to the top job. It’s not out there to wonder why she was picked, and the answer cannot be because « she was there from the beginning ».
You are completely discounting her founder status. She wasn't "there from the beginning", she /created/ the Mozilla Foundation and led it from inception to 2025 and later orchestrated the Mozilla Foundation / Mozilla Corporation split structure (which was the first of its kind and has later been used by other institutions). She was the primary author of the Mozilla Public License. She was the Legal mind behind rescuing the codebase from Netscape by going open source.
In one breath you say this has nothing to do with founder status, because founders are founders, and then completely discount that Mitchell is a founder.
There are MANY valid reasons to criticize Mitchell's tenure at Mozilla, and I haven't seen anyone in this larger thread bring up anything of substance when there are several such things available and well known. Instead this is just a "just asking questions" style of shade-throwing that is unequally applied, and can only be presumed to be because Mitchell is a woman.
It turns out the person I originally replied to didn't even get their women in open source correct, because they were talking about GNOME Foundation and not Mozilla, but I can be forgiven for the mistake as I thought them calling Mitchell a "witch" was a joke about her legal first name Winifred, that she has avoided going by in part due to people taking her more seriously because Mitchell is a gender-ambiguous name. Clearly they have no rational and real basis for criticism if they can't even accurately identify which woman they want to make sexist comments about.
I would encourage you and the person I originally wrote my reply to to both pause and do better.
I'm not discounting her founder status. My point is that it's orthogonal to one's ability to run a company. Founders don't automatically make good CEOs. Plenty of founders step aside for professional management, and plenty stay on and struggle.
Questioning whether someone was the right fit for a role isn't an attack on their legitimacy or their earlier contributions, no matter how pivotal they were. Steve Ballmer at Microsoft had a quasi-founder status, and he received the exact same backlash and hate throughout his tenure because he was perceived as someone who "didn't get it".
If the argument is that any skepticism of a female CEO's performance must be sexist, that shuts down legitimate discussion. I'd rather focus on outcomes rather than on trying to divine each other's motives.
Lastly, Your "pause and do better" is exactly what I'm objecting to: framing disagreement as moral failure. Question Baker? Sexist. Disagree with me? You're not doing enough for the cause.
Zuckerberg's founder status is known because he was Facebook's most visible person always. Baker's founder status is less known because she was not Mozilla's most visible person most years.
Yep, and the US had a lot more leverage; out of the US translates into no access to US dollars either directly or via a correspondent bank, which essentially means bankruptcy.
There's indeed a serious problem if cache invalidation relies solely on the declared semver of the package. Maybe something govulncheck could manage by comparing a package's hash on pkg.go.dev VS the remote vcs.
If you just invalidate the cache on hash mismatch, the malware problem exists the other way around:
You update a dependency to version x and check its code to ensure it's safe. Then the threat actor adds malware to that library you're depending on, and makes the old tag x point to the malicious commit. Yor coworker does "go get" to download dependencies and gets the malware.
One solution (on dev side) is to vendor, which Go has native support for. Another (on Go side) is to show a warning on hash mismatch.
That's why I suggested govulncheck; it can keep a database of suspicious packages and issue a clear warning, and it can be locally check that the hash of tagged version you're using locally is the same on GitHub.
Yeah, it's fundamentally flawed because git tags can be force-pushed over and this has happened on many open source projects in the past, leading to different mirrors hosting different content for the same version.
I don't think this is a valid argument, because both sides of it are true. Developers invested, but so did Apple, and they did it first and took bigger risks.
The App Store is packed with apps because developers saw an opportunity and wanted to seize it. Everyone's in it because it serves their interests.
The iPhone released without an App Store. Their original plan was very clearly to limit it to web apps. Apple, including Steve Jobs, spent a lot of time and energy explaining why web apps were the best option.
And then Apple realized, largely through apps developed for jailbroken phones which led to a lot of people jailbreaking their phones, that for iOS to really succeed they needed apps.
Windows Phone 7 is another example of this. It was a superior OS to iOS by most measures. It died almost entirely because of the lack of major apps.
If major app providers (Google, Spotify, Netflix, etc) had never made their apps available on iOS and had made them available on Android instead iOS would probably be looking like Windows Phone 7 right now.
There's not a single mention of Apple Music. There goes the credibility of this statement.
It's rather obvious that problems started when Apple decided to build a services business the size of a F100 company by directly and unfairly competing with said developers, unchained from all the constraints and costs they impose on them.
Context: I’ve been working in a regulated monorepo and realized that almost all existing supply chain tools assume you are a large enterprise with dedicated infrastructure.
The gap I found:
Scanners are reactive (they yell at you after the fact).
Artifactory/Nix are heavy (they require rebuilding your workflow or hosting servers).
I wanted something in the middle. The idea is a lightweight CLI that acts as a local proxy to gate npm/cargo/go requests against policies stored directly in git. It forces "lockfile intent" (what the dev wants) to match "security policy" (what the repo allows) before the package hits the host.
The mechanism I'm most interested in feedback on is the enforcement logic: sbom check --policy-from=origin/main
This allows the CLI to judge the "crimes" on your feature branch against the "laws" defined in main. It effectively prevents a developer from un-banning a vulnerable package in the same PR that introduces it.
Does this "local proxy" approach feel like the right middle ground to you, or is the overhead of a proxy too much for a daily driver?