Live data from Hacker News

AI-Generated GitHub Copilot “Autofix” Allowed Compromise of Snowflake's Jira

wiz.io

101–110 of 179 posts

Re: AI-Generated GitHub Copilot “Autofix” Allowed Compromise of Snowflake's Jira

#101
post #9

> a single quote in the title breaks out of echo '...' and allows arbitrary command execution. Quote injection still alive and well in 2026. Gawd.

It's appalling that computing in general, and unix in particular, seems to have this habit of intermingling payload and overhead. It's like in-band signalling in the telephone network, where if you whistled the right tones into your call, you could affect the way the network processed said call. Except Ma Bell responded to that system being exploited by designing a comprehensive overhaul of the way signalling was han…

And now the "AI" industry is doubling down on it - with hatbot prompt injection.

Re: AI-Generated GitHub Copilot “Autofix” Allowed Compromise of Snowflake's Jira

#102
post #44

Earlier quoted context omitted.

This is a really cool tool! Would zizmor have caught the below as well? From the article: > The workflow had an if: condition that appeared protective: > if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]') > However, on issues events, github.event.pull_request is always null. So the condition reduces to (null != 'whitesource-for-github-com[bot]'). This is a…

zizmor wouldn’t catch that condition at the moment, although it does have similar checks for other unsound conditions and incorrect/vulnerable bot actor checks. This one wouldn’t be too hard to add, though. (Source: I am zizmor’s maintainer.)

That would be awesome - and thanks for your work, I'll want to start using it!

Nullable event payloads silently null-coalescing to '' are a real "spooky action at a distance" kind of issue, because something that works perfectly when running and being QA'd on PRs, can silently fall apart if made to also run on the main/develop branch (which is only really monitored if the "build breaks," and thus a silent failure or skip might easily sneak through).

Our codebase indeed has comments like this, without which we'd be totally lost:

    # Note contains('') is false if there is no PR at all e.g. on a push to develop,
    # so this will always run on pushes to the develop branch.
    if: ${{ !contains(github.event.pull_request.labels.*.name, 'ci-skip-backend') }}
I imagine that's true of others as well!

Re: AI-Generated GitHub Copilot “Autofix” Allowed Compromise of Snowflake's Jira

#103
We're going to see more of this before we see, hopefully, substantially less of it.

What I'm seeing now in industry -- and I think this autofix issue is a precise example of it -- is a natural evolution of the "LGTM!" review that's so prevalent in software development and similar disciplines.

For years, the dramatic majority of "code review" was a quick glance followed by "Looks good to me." Sure, critical workflows have more scrutiny. Sure, not everyone fell victim to this trap. Sure, there are many exceptions. But it's a meme for a reason: most people weren't really reviewing code assigned to them. They were effectively rubber-stamping most things.

So now, in the age of AI, those same people are (sometimes still) expected to be responsible for what their automated developer friend Claude is doing. It's absolutely unreasonable to think that most people are giving the PR more than a glance, and in many organizations they're explicitly trying to remove humans from the loop.

One day, AI development and code review will be so good that mistakes like this will be extraordinarily rare. For the near-future, though, I anticipate we'll see more of this before we see less.

Re: AI-Generated GitHub Copilot “Autofix” Allowed Compromise of Snowflake's Jira

#104

We're going to see more of this before we see, hopefully, substantially less of it. What I'm seeing now in industry -- and I think this autofix issue is a precise example of it -- is a natural evolution of the "LGTM!" review that's so prevalent in software development and similar disciplines. For years, the dramatic majority of "code review" was a quick glance followed by "Looks good to me." Sure, critical workflows…

lol keep dreaming bro, mistakes like these were "extroardinarily rare" before LLM companies reared their thieving hands.

Re: AI-Generated GitHub Copilot “Autofix” Allowed Compromise of Snowflake's Jira

#105
post #6

Earlier quoted context omitted.

^^ Absolutely. Nothing in the PR jumps out as a red flag. Unless you know how the internals work, I suppose.

Shouldn't anyone reviewing such a PR know how the internals work?

Not anymore, it seems

Re: AI-Generated GitHub Copilot “Autofix” Allowed Compromise of Snowflake's Jira

#106

We're going to see more of this before we see, hopefully, substantially less of it. What I'm seeing now in industry -- and I think this autofix issue is a precise example of it -- is a natural evolution of the "LGTM!" review that's so prevalent in software development and similar disciplines. For years, the dramatic majority of "code review" was a quick glance followed by "Looks good to me." Sure, critical workflows…

lol keep dreaming bro, mistakes like these were "extroardinarily rare" before LLM companies reared their thieving hands.

“There is absolutely no way Bitcoin will ever trade for more than $200.. Impossible!” he said.

Re: AI-Generated GitHub Copilot “Autofix” Allowed Compromise of Snowflake's Jira

#107
post #40

Earlier quoted context omitted.

No. A Snowflake maintainer opened a PR, Copilot suggested a change (introducing a vulnerability), the maintainer accepted and committed it to their PR, and another Snowflake maintainer approved and merged the PR.

I don't see anything in the article that says that two maintainers, let alone one, reviewed the PR manually and approved it before merging. Where are you getting this information from?

Admitting that there was human review from not one but two maintainers would entirely defeat the purpose of the article, which was to sell you an AI solution to the AI problem and insist that no human in the loop is better. Which, to be fair, in this case might have been better.

Re: AI-Generated GitHub Copilot “Autofix” Allowed Compromise of Snowflake's Jira

#108
Sheesh these anti ai posts feel like when I hear about a self driving car is doing something bad.. ie 'man bites dog' vs 'dog bites man'

Human responsibility over AI oversight folks.. even forgoing AI, we're still gonna get compromised code either way.. deal with it.

Re: AI-Generated GitHub Copilot “Autofix” Allowed Compromise of Snowflake's Jira

#109
post #50
post #39

Earlier quoted context omitted.

I have seen plenty of "my backlog has never been shorter" comments here. I'm interested in how that turns out 6 months later. In my team, we have plenty of enhancement requests from users. We address those that make obvious sense and are trivial to do but withhold from others, even though the code change itself is likely small. Because we don't know if there is more than a single user that can actually benefit from i…

> but withhold from others, even though the code change itself is likely small. Prediction: programming is going to change massively not only because the cost of creating code will go down, but because people are so tired of this sort of gatekeeping "we know better" from programmers.

Can you explain to all of us how this gatekeeping is actually bad? Software would be way, way worse if we just allowed any arbitrary feature to be added to software, and ordinary people who want all the things would have to learn, the hard way, that doing all the things is not actually good.

Re: AI-Generated GitHub Copilot “Autofix” Allowed Compromise of Snowflake's Jira

#110
post #19

YAML is a nightmare fuel spec. In its quest to make markup "human readable", it has created countless footguns. I honestly prefer XML at this point.

In a similar vein, JSON's lack of comments makes me marvel at how consistently JavaScript seems to choose the worse option. I'm oh so glad it found its way into config files

As a data/serialization format (the original intended use of JSON), I think no comments is the right choice, since adding comments introduces a bunch of questions about how comments ought to be parsed into a datastructure (or if they should be sent/(de)serialized at all). But for config files the lack of comments is the wrong choice, since typically you want to explain why things are set the way they are. The lack of ordering of entries also makes total sense for data/(de)serialization, but makes no sense for a config. I think the problem is people are lazy and just want to JSON.parse() everything, and used JSON in places it doesn't belong, like config files.
Post reply on HN