HN

Comments (94)

• Menu

  inahga
  I probably would have made the same mistake. It is negligent to write GitHub Actions without using static analysis.Use zizmor in CI https://github.com/zizmorcore/zizmor error[template-injection]: code injection via template expansion --> .github/workflows/jira_issue.yml:24:29 | 22 | run: | | --- this run block 23 | # Escape special characters in title and body 24 | TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\'/g") | ^^^^^^^^^^^^^^^^^^^^^^^^ may expand into attacker-controllable code | = note: audit confidence → High = note: this finding has an auto-fix
• Menu

  mjr00
  It's interesting to look at what was being attempted when the vulnerability was introduced[0]> Workflows like jira_close.yml use deprecated atlassian JIRA actions and have a dependency on the gh-actions repo. This is not ideal and unecessarily complex. PR updates jira_close workflow to use direct API calls via curl. It preserves custom fields used too.I won't speak to this projects' management and how they prioritize things, but from my own experience, pre-AI, this type of change would have been firmly in the "this is a minor annoyance, put it in the Tech Debt Backlog alongside the 50000 other tickets" and never actually done. The cost of a human investing the time understanding how to fix the problem, doing code changes, testing them, and deploying them is just way too high for what actual value this change brings, which is close to nothing.Now with AI, it's as simple as firing up an agent and telling them to make a change; as much effort as writing that backlog Jira ticket in the first place.Similar to the problem open source is having with low-value PRs, companies are going to have to start realizing that code is not free to review or maintain, even when it's generated for ~free, in their internal processes. Just because an agent can fix a minor tech debt annoyance with a few lines of instructions doesn't mean it should.[0] https://github.com/snowflakedb/snowflake-connector-net/pull/...
• CodeWithLeo
  The interesting lesson here isn't really “AI generated insecure code.” We've had insecure code for decades. The bigger issue is that AI makes it much cheaper to introduce changes, while the cost of reviewing those changes hasn't gone down nearly as much.The bottleneck is moving from code generation to code verification.
• Menu

  procone
  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.
• nevertoolate
  They didn’t really sell this PR well:> Workflows like jira_close.yml use deprecated atlassian JIRA actions and have a dependency on the gh-actions repo. This is not ideal and unecessarily complex.And then goes on:> PR updates jira_close workflow to use direct API calls via curl.Duplicating the logic into OUR codebase via a hand rolled curl, so we can get rid of “needless abstractions”. Auch. And of course the whole thing embedded into a yaml file.This code is the typical kaleidoscope sometimes written by junior devs (and LLMs). On review you just kindly ask to be rewritten into a simple program or just close it as the effort doesn’t worth it.
• Menu

  vultour
  The first linked PR (#1218) has only one commit co-authored by Copilot and it's not related to the vulnerability, and neither are the other suggestions in the PR. Am I missing something?
• Menu

  sippeangelo
  The title is actually "Wiz Red Agent Finds Its Way Into Snowflake’s Internal Jira Due to an AI-Generated GitHub Copilot Autofix"
• tripdout
  Why is the original pattern (with the env var in double quotes) not vulnerable? Why can you close the single quotes early but you can't just include double quotes in your title? Is it something to do with the GitHub templating?
• cowthulhu
  This really shows why most languages evaluate all NULL comparisons to FALSE.For something as critical as Actions, it’s crazy to me that they wouldn’t fail-closed, and instead fail open when encountering a null. Scary stuff!
• teraflop
  > 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.This is extra dumb because even if you thought this condition was correctly testing the user's identity, it shouldn't have "appeared protective" upon even a moment's thought. If it worked correctly, it would obviously just exclude one bot user while allowing all other users, so it wouldn't provide any protection at all.But more likely, this condition was never intended to be "protective" at all, and it's only being described that way because the writeup is LLM slop.
• Menu

  johnwils
  The env + jq was there on purpose. Autofix swapped it for a string in a shell. That's the part that needed a person on the diff.
• Menu

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

  TheRealPomax
  No, Snowflake allowing autofixes compromised their Jira. If you tell someone to shoot you in the foot, and they shoot you in the foot, you shot yourself in the foot, just with more steps. If someone else finds the memo that says you've set up foot shooting as a service, and then they trigger that service, you still shot yourself in the foot.
• kozikow
  Issues will happen AI, or not AI. It's same as "self driving car made an accident"!I'm not saying blindly trusting auto-fix is not bad. I'm just saying that interpreting singular issue as way to downplay AI-assisted engineering without giving a "denominator" is not honest reporting.
• Menu

  forestry
  Peer review of changes is still important.
• mhrsntrk
  [flagged]
• beyondscale-sha
  [dead]
• antiloper
  Someone forgot to add "make no mistakes!" when triggering autofix /s