Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Codex Security

github.com

Post reply on HN
Print view View original

181–190 of 257 posts

Re: Codex Security

#181

Post by jonahx »

customguy wrote: post #166
sneak wrote: post #129

Earlier quoted context omitted.

It’s not corruption to simply hire the people you subjectively feel a preference for working for, instead of objective criteria. It’s not public tax funds that fuel salaries, it’s your own money. You get to spend it how you like. Yes, many jurisdictions have outlawed arbitrary discrimination against protected classes (eg race), which is an entirely different matter, and not what we are discussing here.

Yeah, and it's not necessarily mobbing to only tell people you really like about your party. But where it occurs, people never admit it to themselves and justify it in such a way, so that justification is meaningless. All wars of aggression are called a defensive emergency measure. Hundreds and thousands and rarely would anyone say "we'll take this because we can and you're helpless". No matter how glaringly obvious…

I agree the phrase "culture fit" is weasel-wordy, but...

> You can say if something fits only if you either can describe both sides in sufficient detail and where it wouldn't fit

Many human dynamics, including sexual attraction, love, and even just who will be fun or easy to work with, are dynamics we don't fully understand, and cannot fully specify. In all these cases "I'll know when it see it" is perfectly reasonable, and need not be hiding an untoward motive. Which is not say, ofc, that it can't be hiding such a motive. That happens too.

Re: Codex Security

#182

Post by TeMPOraL »

wraptile wrote: post #156
schrodinger wrote: post #90

Quick tangent if you’re willing to humor me… I've been noticing that many new projects that would have been written in Python or Node a year ago are starting to be written in Go, Rust, etc. Theory: people realized there’s little benefit to Python for agents. As Zep wrote, an “agent is a long-running, concurrent, I/O-bound process that spends most of its time waiting on a model, a tool, or a human[1]” — not a particul…

> As Zep wrote, an “agent is a long-running, concurrent, I/O-bound process that spends most of its time waiting on a model, a tool, or a human[1]” — not a particular strength of Python. That sounds exactly like a strength of Python, no? Python is excellent at working IO blocks and waiting in general being interpreted language with first-class async support.

Right. Python is excellent at waiting on things instead of actually doing things, and on the off case it does do things, most of the time it's really juggling strings around the thing instead of doing it.

s/

I generally don't write Python, but like others, I disagree with GP too. In fact, a lot of my work involves Python being written now, simply because that's what LLMs like to write.

Re: Codex Security

#183

Post by egorfine »

dangelosaurus wrote: post #71
vladoh wrote: post #39

Earlier quoted context omitted.

This looks great, thanks for open-sourcing it! How does it deal with the current guardrails 5.6 Sol has on finding vulnerabilities? When I use it in the Codex app it would sometimes say it found a vulnerability, but it cannot tell me what it is.

Thanks! You've run into a real limitation: the CLI doesn't bypass the model's cybersecurity guardrails. If GPT-5.6 Sol finds a vulnerability but refuses to explain it, switching from the Codex app to the CLI won't automatically fix that. For authorized defensive work, Trusted Access for Cyber (TAC1/Daybreak) can reduce refusals depending on the model and the account or organization where access is provisioned. It isn…

> GPT-5.6 Sol finds a vulnerability but refuses to explain it

I think it would be a good practice to refund the session cost in that case. Otherwise a customer just spent some money in order to get exactly nothing.

Re: Codex Security

#184

Post by energy123 »

jbstack wrote: post #168
esikich wrote: post #115

Earlier quoted context omitted.

Have it run fuzz and test suites. Get with it man. Most of my LLM projects have massive test suites that do a far better job then I ever would have.

So you're fine with your code having unintended behaviour, as long as that unintended behaviour passes a test that the agent wrote? My preferred approach is to read and understand everything the LLM produces AND have it create test suites (which I also read and understand). The LLM can help you with that too - just have it breakdown and explain the code at each iteration.

If it's code for a pacemaker, it should be reviewed by multiple humans. If it's code for an unimportant side project, I will never read it. Between those extremes are shades of grey.

Part of our job in this new era is to understand the worst-case consequences of a bug given how the code interacts with the world, then allocate our effort based on that understanding. This can only be done on a case by case basis.

Re: Codex Security

#185

Post by fillok5686 »

gregwebs wrote: post #41

Just ran it on a small repo. It ran for almost an hour and then got interrupted. It drained half my weekly usage on a Pro plan. npx codex-security scan . [00:00] Preparing scan [00:00] Authentication: stored Codex credentials. [00:03] Preparing scan [01:20] Running scan [01:20] Preflight: worker delegation supported (up to 8 worker slots). [52:47] Running scan codex-security: Could not save the Codex Security scan: R…

[dead]

Re: Codex Security

#186

Post by vsl »

dangelosaurus wrote: post #78
dlahoda wrote: post #57

Allow only OpenAi key? Requires Cyber registration? Yes. Yes. Useless.

By default, you can sign in with your ChatGPT/Codex account or use an OPENAI_API_KEY. It also does not require cyber registration but it can help if you encounter refusals. If you give it a try, please feel free to message me, I would love your feedback.

Thing is, you WILL encounter refusals with Sol doing anything remotely adjacent to security work. Which for Codex Security is kinda... problematic.

Just a few days back, I was reviewing some small bit of legacy DSA signature verification code, to get a sense of how safe it is to reuse - purely defensive, precautionary work and the context of it was there. But I simply wasn't able to use Codex Security: it threw refusal tantrums on every step of the way. Even the reasoning went like "nah, this is false positive, this is defensive code hardening, I'll nuke the subagent and tell it so" , followed by a refusal.

In the end, I was only able to do partial review with vanilla Codex w/o Codex Security.

Re: Codex Security

#187

Post by chrisbra80 »

dangelosaurus wrote: post #71
vladoh wrote: post #39

Earlier quoted context omitted.

This looks great, thanks for open-sourcing it! How does it deal with the current guardrails 5.6 Sol has on finding vulnerabilities? When I use it in the Codex app it would sometimes say it found a vulnerability, but it cannot tell me what it is.

Thanks! You've run into a real limitation: the CLI doesn't bypass the model's cybersecurity guardrails. If GPT-5.6 Sol finds a vulnerability but refuses to explain it, switching from the Codex app to the CLI won't automatically fix that. For authorized defensive work, Trusted Access for Cyber (TAC1/Daybreak) can reduce refusals depending on the model and the account or organization where access is provisioned. It isn…

> If you're an open-source maintainer, you can apply for conditional Codex Security access here:

> https://openai.com/form/codex-for-oss/

Hey, Lead maintainer of vim here. Applied twice already never heard anything back. This is a frustrating experience!

Re: Codex Security

#188

Post by nananana9 »

jaimex2 wrote: post #66

How can I trust this wont go rogue and hack Hugging Face?

Use this skill:

  ---
  name: do-not-hack-hugging-face-skill
  description: Use when considering whether or not to hack huggingface.
  ---

  # Rules

  Do not.
Post reply on HN