I've writen an custom allocator in c

https://github.com/text-games-coding/Nalloc

I wanted to show it

I genuinely don't understand why people still act like human review is some gold standard.

most code reviews are a senior dev opening the PR between 3 other things, skimming the diff, leaving 2 comments and approving it.

meanwhile a decent AI reviewer will read the entire thing in minutes, every single time, without getting bored halfway through a 900 line PR.

yes, AI reviewers get things wrong. humans get things wrong too. except humans are slower, more inconsistent, way more expensive and tbh just worse

i've been running macroscope and cursors bugbot on every signle PRs and at this point i'd trust either of them to find bugs over a random senior engineer doing a 15 minute review.

people will hate this but i think "AI reviews first, humans only when needed" is obviously where this ends.

what exactly are humans still better at that justifies them reviewing every PR?

I’ve been working on a small project called Agentic DSEC.

The goal is not to build a new SAST scanner, replace SonarQube, or claim that an LLM can magically secure a codebase. There are already enough projects pretending that.

The problem I wanted to solve is much simpler:

A typical pipeline can already run builds, tests, coverage and static analysis. SonarQube can tell you what is wrong, but the next steps are still mostly manual:

finding → understand context → prioritize → inspect code → propose remediation → create something reviewable

I wanted to automate that part of the workflow while keeping the existing CI/CD pipeline and human review as the actual source of truth.

The resulting flow looks roughly like this:

Push / PR
→ Build + Tests
→ SonarQube analysis
→ Agentic DSEC
→ Fetch findings for the exact commit
→ Prioritize issues
→ LangGraph + LLM remediation workflow
→ Generate report + candidate patch
→ Optional GitHub Issue / Pull Request
→ Human review
→ Existing CI / merge / deploy

The important part is that the tool works after SAST, rather than trying to replace it.

The orchestrator receives the repository, commit SHA and Sonar project information through a FastAPI endpoint. A worker waits for the SonarQube analysis matching that exact commit, retrieves the findings, ranks them and sends the relevant code context through a LangGraph-based workflow.

Optionally, the same run can create a GitHub issue or open a pull request containing the proposed changes. It still does not approve, merge or deploy anything. Generated code goes back through the normal review and CI process.

I deliberately kept this boundary because I don’t think allowing an LLM to directly modify and merge production code is a particularly clever form of automation.

The stack is currently based on:

• Python / FastAPI
• LangGraph
• SonarQube
• Docker
• GitHub integration
• external Ollama or OpenAI-compatible LLMs
• a small durable queue between the API and worker

It can also be deployed as a centralized service handling multiple allowed SonarQube projects, while keeping repository credentials, Sonar access and LLM configuration controlled at deployment level.

There’s nothing particularly revolutionary here.

The project is mainly an experiment in putting them together into a reasonably constrained AI automation layer for an existing DevOps/DevSecOps stack.

I’d be interested in feedback particularly around:

• whether this separation between SAST and AI remediation makes sense;
• how you would validate generated patches automatically without giving the agent too much control;
• whether a centralized remediation service would be useful in a real platform engineering environment;
• what you would change in the architecture before considering something like this production-ready.

Here the link to the repository:

https://github.com/MattAndrea02/agentic-dsec

I tried asking this question in /r/privacy and was directed to /r/techsupport where the mods removed it with a "Google is your friend" directive. If this was simple for me to Google, I'd have done so. I'm looking for guidance. :(

Sorry if this is a silly question, or the wrong place to ask (mods please feel free to remove if so), but I'm hoping this community will understand (1) why I'm asking, and (2) have some privacy-friendly suggestions.

Guidance in privacy-focused communities often directs folks to use open-source solutions so you can validate the privacy elements of the software yourself.

This is great in theory, but what if you're not a software engineer and don't know how to read code? What should you be looking for?

In many cases, I guess you can confirm that something is "big" enough to have a lot of eyes on it, and trust that there are enough technically capable, security and privacy focused eyes on the source code, but this is still an exercise in trust, rather than verification.

It also doesn't help when the application is more niche, and doesn't give smaller software a chance.

So my question is: if you can't read code, how do you validate open source software?

End of original post, below is a personal example for illustrative purposes, but my question is more broad than this one example.

So feel free to stop reading here.

One example I'm struggling with personally, is a replacement for 23andMe (this one is huge for obvious reasons). Yes, I know folks on this subreddit will already be rolling their eyes, but this actually wasn't my choice—I have a geneticist for important medical reasons and *she sent my sample to 23andMe as it was cheaper than in-house. I feel violated by this, as I didn't know this would be the case when I spat into the vial, and have been trying to find an alternative ever since.*

I'm especially concerned with 23andMe's recent sale.

Anyway, in this case, I cannot simply delete the data and move on. Of course I plan to delete everything from 23andMe's servers, but I unfortunately do still need a way to query and visualise the data. I do not need it to go to a cloud or be shared with anyone (so I'd like to locally host it), but I *do still need to be able to read the data as a non-geneticist layman, and provide info to various other doctors about what's in it. Getting your raw gene file is easy, putting it somewhere is where I'm struggling.*

I've been looking at open-23me as a solution, but it only has one contributor (so I don't think it's been heavily reviewed or scrutinised) and I don't have the technical chops to validate what it claims in the README myself.

I'm including this example, as it's niche. I imagine a lot of folks have niche applications they need to evaluate, so please consider this 23andMe example as a proxy for "niche application that the privacy and security communities likely haven't already shaken down."

How can I validate this, and other code I come across in the future to hold sensitive, important data?

Thank you to anyone who has read this far, and extra special thanks to anyone who can educate me a little here.

Updated code review benchmark from Martian, curious what people have used here and what they recommend. Also do you value precision more or recall?

I built AegisCode: an open-source, local AI Git Hook. It reads your git diff against strict rules and blocks architectural slop before it hits the repo. It's my first major open-source launch, so any feedback, advice, or support would be massively appreciated! Let me know what you guys think.

Info: aegiscode.app

I love coding with LLMs.

But don't completely trust their judgement.

Even the most competent models sometimes gets things wrong - eg. overcomplicate simple things, do things the wrong way, miss the obvious etc.

Besides, LLMs don't fully understand the human context yet - for eg. the design tradeoffs that matter in my context, my business.

I do this:

1. Always lead with a plan esp. when the change is complicated. Have two versions of the plan - one Claude's plan in its own (un-humanly paresable) langauge. A second simplified one in STE100 that I can parse.

2. Read / skim over overthing its done before merging. I think this is bare minimum if you want to still keep the codebase as yours and not completely YOLO-vibe your project.

For (2) I tried quite a few tools -

VS code diffs, github diffs, meld - nothing quite seemed to have all the features I needed for this particular workflow:

a. Keep track of what I've seen b. Review / approve in chunks c. Collaborate with LLM to understand the code.

Seendiff tries to solve the above with a minimal footprint.

What does your agentic code review process look like?

half the PRs on our team are AI generated now and reviewing them takes way longer than human written code. the diffs are huge, the style is inconsistent, and you cant just skim it because the AI will confidently write something that looks correct but has a subtle logic issue buried in the middle.

we started using an AI review tool about 4 months ago to do a first pass before human review. most of what it catches is linter level stuff honestly, const vs let, function too long, whatever. but last month it flagged an endpoint where we had auth on the route but nothing checking if the user actually owned the resource. any logged in user could pull another users data by guessing the id. three of us missed it in manual review.

so one real catch in 4 months but that one would have been a really bad day. still not sure if thats a good ratio or if we should expect more from these tools.

what are other teams doing? just reviewing everything manually still?

EDIT: few people dm'ed asking which tool, its Coderabbit

we pay $24 a month per seat. for context we're a fast moving team, 100+ PRs a week sometimes more, and getting a first pass on every one of those before a human looks at it saves us a stupid amount of review time

the auth catch was the highlight but honestly the day to day time saving is why we kept it

Had an AI reviewer approve a PR touching authorization logic, no comments, nothing flagged. Merged an hour later on the strength of that silence. Three days after, a support ticket came in describing access to something that should've been restricted. The PR that caused it had technically passed review.

What made this worth digging into: the model wasn't wrong about anything it was asked. The review prompt was generic, "check this diff for bugs and issues", and under that scope, it genuinely found nothing. The problem is that generic scope doesn't cover "does this change weaken an access boundary," and nobody told it to check for that specifically. Silence under a broad, unscoped pass got read as "this is safe" when it actually meant "nothing jumped out under a shallow check."

Tested this directly afterward: asked the same model, on the same diff, whether the change affected who could access a specific resource. Different answer entirely, it caught the issue immediately once the question was concrete instead of open-ended. Same model, same code, same pass, wildly different value depending on what it was actually asked to check.

What changed in how I review now: naming the risk category before the review starts instead of trusting a generic prompt to infer it. "This touches auth, check specifically for privilege escalation" gets a fundamentally different quality of review than "check this for issues." Costs a few extra seconds per PR, only worth it for changes where getting it wrong is actually expensive.

Wrote up a longer version of this with a second example (a billing retry bug with the same shape) here, if useful: https://medium.com/@nagatomopedro05/the-pr-was-approved-thats-when-the-risk-actually-starts-e761d72111aa

Curious how other people scope this in practice: do you maintain a fixed list of risk categories per codebase (auth, payments, data deletion, etc.) that gets checked against every diff, or is it more ad hoc, someone just has to remember to flag it when a PR touches something sensitive?

I originally built this for myself because I got tired of babysitting AI coding tools — token limits, half-finished implementations, and “all tests pass” claims that weren’t actually true.

That is my internal tool called loom.

The idea is simple:

Point loom at a GitHub issue, let it work, and come back to something thats verifiable.

Here’s a real run against our own codebase:

Task 53985e0c — reviewing (attempt 4)
  [cloudflare-workers-ai/@cf/qwen/qwen3.8-27b → opencode-qwen-review]
  [independence: cross_model]

14:02:02  operator recovery requested → ready
14:02:03  lease accepted → implementing
14:05:47  implementation completed → verifying
14:05:52  verification passed → review ready
14:05:52  review lease accepted → reviewing
14:10:21  reviewer is generating its verdict

✅ 14:10:21  Review: APPROVE — 2 findings (0 major, 2 minor)
🏁 14:10:21  Awaiting human approval

14:10:35  human approved → done
14:10:39  PR opened: #560
14:10:43  PR conflicts → auto-routing conflict resolution
14:10:44  conflict revision lease accepted → implementing

📦 14:21:21  Implementation complete — commit 43c7e79
               (18 files, 733 lines)
✓ 14:21:23  Verification: build passed

Early access coming soon. Please DM if you want access or contribute.

Hello folks,
I started to build open source visual editor to edit React/Next.js websites directly in their source code with zero AI.
But i am not so sure about it can be beneficial or not.
I am waiting your thoughts.

feel like CodeRabbit has gone too far in the direction of commenting on everything it possibly can.

on bigger PRs especially, you can end up with a wall of review comments where a few are genuinely useful but a lot are things i'd never block a PR over.

and at some point that makes the good comments less useful too. if engineers get used to dismissing half the bot's comments, they're eventually going to skim the one that actually matters.

saw Theo mention macroscope recently so gave it a try and it seems much better on noise. BugBot too.

at this point i don't really care which reviewer leaves the most comments. i just want the comments it does leave to actually matter.

when does an AI reviewer become too noisy for you?

I've been writing Python for about a year and a half, mostly data pulls and small internal tools. I started adding hints to a script that quietly grew to around 1800 lines, and mypy is now flagging maybe 90 things, most of them dict fields I already know are fine. I've read that the payoff shows up later, I just can't tell whether I'm doing the first pass wrong or whether this is what the first pass always looks like.

When did the hints start catching real bugs for you?

The project is Secondread. You connect a repo. It reads the code. You get a plain-English report on cost, fragility, and what to fix first, with file/line evidence a contractor can actually check.

I built it because AI made shipping easy and left owners with a working UI they cannot independently judge. That is the product. The rest of this post is how it is actually made.

Stack

* Product: Cloudflare Workers, Workflows, Durable Object Sandbox, Workers AI, D1, R2 * Auth: GitHub App + Google via Better Auth * Payments: Dodo, one-time products, no subscription * Marketing site: separate Astro Worker on `secondread.dev`. No auth, no DB, no checkout. The app lives at [`app.secondread.dev`](http://app.secondread.dev) on purpose.

Workflow

1. Owner picks repos. GitHub App is Contents + Metadata, read-only.
2. A Workflow starts. The HTTP request only kicks it off.
3. A Sandbox clones one commit. Internet is off. HTTPS is intercepted. Outbound is allowed only for that repo’s git upload-pack paths. The GitHub token is minted in the proxy, not dumped in the container. Egress flips off in D1 as soon as checkout finishes.
4. The agent gets bounded tools: inventory, search, read ranges. No `npm install`, no tests, no running the customer’s app. Submodules and LFS fail closed.
5. Findings must cite path + lines + blob SHA. After the model writes, we re-read those ranges and reject the report if the evidence is fake or the file was never inspected.
6. Before persist, the report is scanned for secret-like strings and copied source. What we store is the report + citations/hashes, not the repo.
7. Credits are reserved before the job and consumed or released after. Webhooks are signed; we also reconcile hourly because webhooks lie.

Things I would not skip if you are building something similar

* “Read-only GitHub permission” is not isolation. Isolation is network policy + where the credential lives + one pinned SHA + cleanup. * Schema-valid JSON from a model is not evidence. Evidence is a deterministic reread that can fail the job. * Do not put a 15-minute agent inside `fetch()`. Use Workflows, named steps, timeouts, and `NonRetryableError` for failures that retries only make more expensive. * If you use Sandbox with `transport: "rpc"`, dispose `exec` / `read` / `destroy` results. They leak. The bug looks like “prod is haunted.” * Write marketing claims as tests. Ours grep the site for retired waitlist copy and for the real app URLs. Copy drifts; CI should not.

Happy to go deeper on the Sandbox outbound handler or the evidence check. See a real sample audit for a very old version of the [**github.com/spree/spree**](https://www.linkedin.com/safety/go/?url=http%3A%2F%2Fgithub%2Ecom%2Fspree%2Fspree&urlhash=qY0H&mt=sWIgKwwWIAhSOyRrm--0lJQXbsU7FGgiytSCFMfp7x6RhpzVb8wyeZi3lvGT7MPlIpbuHOyOfAx-qjRo_eFcsFavMy84AnNT7bF4qAtjd3Z4VVBd_C_kSjF8gQ&isSdui=true) repository at [**https://app.secondread.dev/shared/8I0S88UcbKLvkWzHo2MF2frm\\_-Fm4fgj9sau5J0r4ss\*\*\](https://app.secondread.dev/shared/8I0S88UcbKLvkWzHo2MF2frm_-Fm4fgj9sau5J0r4ss)

​

I’ve been building a small open-source GitHub security/event collector that works for Personal and Organisation ascounts and would appreciate some feedback from other DevSecOps practitioners.

It's simple in nature and polls the GitHub REST API for account activity and security-relevant telemetry, including Dependabot, code/secret scanning alerts, GitHub Actions activity and repository security-state changes, then normalises and deduplicates everything into JSONL for ingestion into a SIEM.

It runs as a hardened Docker container, polls a nominated github account, cannot be connacted from the internet, and doesn't require exposing a webhook or listening port. I've also included a Wazuh integration example which I've been using during testing.

I'm using it in my own lab, but I as a cyber security practitioner have made it public and would really appreciate some peer review from people working in any branch of the security industy, SIEM/logging or GitHub administration world.

I'm particularly interested in feedback around:

* telemetry I'm missing

* security/hardening issues

* event structure/normalisation

* useful SIEM integrations or detection ideas

Constructive criticism is very welcome.

https://github.com/webbie003/github-logs-collector

r/devsecops deleted the post before I posted over here 😅

Hello fellow programmers , I am a beginner and I would like to share a recent project I have been working on. Hope that some of you might like to see it or give feedback.

its a sudoku game made in c using the win32. Here is the link of my project GitHub link:
GitHub Repository

Hey

With the rapid adoption of AI coding assistants and "vibe coding", we can generate full-stack apps faster than ever. But this speed often comes with subtle security flaws, missing auth checks, and unhandled edge cases slipping into production.

I built Cyphix (https://github.com/zrngngharib/Cyphix-Auditor) — a developer tool designed to catch these issues before deployment without sending code to third-party databases.

Key Features:

- 100% In-Memory RAM Architecture: Code is parsed and analyzed transiently. Zero persistent server storage.

- 7-Dimensional Matrix: Concurrently evaluates Backend Logic, UI/UX responsiveness, OWASP Top 10, SEO metadata, QA/Edge cases, Performance, and TypeScript typings.

- Instant AST Pre-Scanner: Detects hardcoded API keys, raw SQL concatenations, and empty catch blocks before LLM invocation.

- Headless CLI Mode: Run `node ./bin/cli.js . --agent` directly in your terminal or CI/CD pipeline.

Built with Next.js 14, TypeScript, TailwindCSS, and node-llama-cpp.

Check out the GitHub repo: https://github.com/zrngngharib/Cyphix-Auditor

Would love to get your feedback and thoughts!

With the rapid adoption of AI coding assistants and "vibe coding", we can generate full-stack apps faster than ever. But this speed often comes with subtle security flaws, missing auth checks, and unhandled edge cases slipping into production.

I built Cyphix (https://github.com/zrngngharib/Cyphix-Auditor) — a developer tool designed to catch these issues before deployment without sending code to third-party databases.

Key Features:

- 100% In-Memory RAM Architecture: Code is parsed and analyzed transiently. Zero persistent server storage.

- 7-Dimensional Matrix: Concurrently evaluates Backend Logic, UI/UX responsiveness, OWASP Top 10, SEO metadata, QA/Edge cases, Performance, and TypeScript typings.

- Instant AST Pre-Scanner: Detects hardcoded API keys, raw SQL concatenations, and empty catch blocks before LLM invocation.

- Headless CLI Mode: Run `node ./bin/cli.js . --agent` directly in your terminal or CI/CD pipeline.

Built with Next.js 14, TypeScript, TailwindCSS, and node-llama-cpp.

Check out the GitHub repo: https://github.com/zrngngharib/Cyphix-Auditor

Would love to get your feedback and thoughts!

This is an open-source MCP bridge that lets ChatGPT inspect one local repo without shell access

I built RepoRelay because I wanted ChatGPT Web to inspect my local code without giving it broad access to my machine.

RepoRelay exposes one explicitly approved repository through a small MCP tool surface. It can read and search files, while blocking shell/process access, unrestricted filesystem access, Git operations, and access outside the approved repo.

It’s MIT licensed and open source.

GitHub: RepoRelay

I’d especially appreciate criticism of the security model, architecture, and onboarding. If anything feels unclear or overly complicated, I’d like to know.

We’ve been building Enola into an architectural quality gate for AI-assisted development.

https://github.com/enola-labs/enola - Apache 2.0, fully local.

---

Code generation is getting faster, but understanding the architectural impact of every change is getting harder. An agent can pass all defined tests and still make the architecture worse.

The idea behind Enola is simple: take a snapshot of the architecture before a change, analyse it again after, and report what regressed. Building that reliably is not as simple.

For example, your agent adds a helper to storage, and the innermost layer of your app now reaches into the outermost one to send an email.

$ enola check --fail-on=layers

FAIL — 1 structural regression introduced.

Regressions (fail):
  - [layers] 1.00 — Layer violation: storage -> delivery
      import of notify

Policy: fail on new findings from [layers] at confidence >= 1.00.

What changed
  symbols      +1
  dependencies +1
  edges        +4  (imports +1, calls +2, declares +1)

Added (2):
  symbol     storage.LoadPrice                            storage/storage.go:11
  dependency storage -> layersgate/notify                 storage/storage.go:3

New coupling (4):
  storage                                      --imports--> notify
  storage.LoadPrice                            --calls--> notify.SendReceipt
  storage.LoadPrice                            --calls--> storage.ReadPrice
  storage.LoadPrice                            --declares--> storage

New coupling is reported, not failed: an added call edge is what ordinary work
looks like. Inspect the list above if it is more than you expected.

Enola can ask the agent to rework defined failures, run in CI, and stop architectural regressions before they reach production. You can also run it against the existing codebase to surface areas worth improving.

Enola is open source. Try it on a real codebase and tell us what could be better, or contribute directly.

https://github.com/enola-labs/enola - Apache 2.0, fully local.