Production Lens

• 

  Production Lens - Main Screen

• 

  Industry reports on current issues with AI generated code

• 

  Guiding principles used in building Production Lens

• 

  Scanning file - checks for Zip boundaries, understand the tech used, check for readiness, and generates a report

• 

  Number of issues found with criticality

• 

  Remediation Screen with details - lines with issues, recommended remediation

• 

  Remediation Screen with impacted guiding principles

• 

  Remediation Screen - technology used in the repository

• 

  Remediation Screen after the patch is applied locally. No source code is changed in the demo version.

• 

  For the demo, there are three files that you can down load to test

• 

  Upload the file from local machine that were downloaded. For this demo not exposing to load any files, as we have to build full boundary

Inspiration

Teams can build an AI pilot in days, but proving that it is ready for production is much harder. The important gaps are scattered across application code, prompts, authorization, logging, evaluation, reliability, and operational controls. A checklist can say what should exist, but it usually cannot show the exact evidence or prove that a proposed fix worked.

I built Production Lens to make that gap visible and actionable.

What it does

Production Lens statically scans an AI application repository without executing it. It returns prioritized production-readiness findings with severity, category, file and line evidence, impact, governing readiness principles, and concrete remediation.

The demo includes three bundled projects. The Enterprise Analytics Agent exposes 11 production-readiness gaps. The Security Test Agent exposes seven evaluated injection risks. For every bundled finding, a user can review one deterministic recommended patch, explicitly approve or defer it, apply it only to a disposable copy, rescan, compare resolved and remaining findings, detect newly introduced risks, and reset to the exact baseline.

How I built it

Production Lens is a TypeScript and Next.js application deployed through Vinext on a Cloudflare Worker. Scanner behavior is isolated in lib/scanner; UI components contain no detection logic. Repositories are represented as bounded text and are never imported, installed, built, or executed.

The scanner uses stable rule IDs, centralized file and byte limits, secret redaction, deterministic evidence, technology applicability states, and an inert self-scan of Production Lens itself. The remediation engine requires exact before-text, explicit approval, disposable-copy mutation, and deterministic rescan verification.

I also built and evaluated the secure boundary for future ZIP ingestion: path and collision rejection, special-entry checks, compression-bomb limits, CRC validation, strict decoding, disguised nested-archive detection, owner/tenant authorization, rate and replay policies, source-free operational events, and a release-blocking adversarial corpus. Arbitrary uploads remain disabled until real quarantine and malware-scanning infrastructure passes its gates.

Current scope and framework roadmap

Production Lens is a principles-based deterministic review tool, not a certification product. Its current catalog covers declared high-signal patterns with file-and-line evidence, explicit applicability states, and tested remediation for bundled findings. It partially covers selected OWASP, CWE, and NIST-aligned concerns, but does not claim formal or complete coverage of those frameworks.

The next framework milestone is a published, rule-level crosswalk:

• CWE: attach the applicable weakness identifiers to every implemented rule. A CWE mapping will describe the weakness addressed; it will not imply complete CWE coverage.
• OWASP: map each supported rule to applicable OWASP Top 10, OWASP LLM Top 10, and ASVS topics, with a visible supported-language and evidence boundary.
• NIST: map the governance and engineering checks to relevant AI RMF and Secure Software Development Framework outcomes, while retaining explicit “implemented but unverified” and “needs review” states.

The planned implementation sequence is intentionally bounded:

1. Publish the framework crosswalk for the current deterministic catalog before expanding claims.
2. Expand the injection rule pack through its declared parser, template, protocol, identity, and advanced-AI waves, one evaluated language/framework scope at a time.
3. Complete deployment-backed ingestion and operational controls before enabling hosted arbitrary uploads.
4. Enable any runtime model analysis only after Milestone 4 isolation, validation, adversarial, budget, and capability-separation gates pass.

Until then, the accurate product claim is: Production Lens provides deterministic, principles-based checks that partially overlap with OWASP, CWE, and NIST concerns.

How I used Codex and GPT-5.6

Codex was the primary engineering collaborator throughout Build Week. It:

• Translated the product idea into milestones, trust boundaries, and evaluation gates
• Built the scanner, UI, deterministic sample snapshots, and expected-finding tests
• Added evidence redaction, file/path limits, security headers, and self-scan invariants
• Expanded injection coverage using paired vulnerable and secure-equivalent fixtures
• Built explicit remediation approval, disposable-copy patching, rescan, comparison, and reset
• Implemented secure ZIP inspection and bounded materialization without executing repository code
• Developed authorization, admission, audit, alert, and adversarial-evaluation boundaries
• Repeatedly ran tests, production builds, dependency audits, and end-to-end checks

GPT-5.6 was especially valuable for the complex work: security architecture, threat modeling, injection-rule design, remediation safety, adversarial fixtures, authorization boundaries, capability separation, and release-readiness decisions.

The project uses the GPT-5.6 family deliberately:

• Terra is the project’s everyday development default.
• Luna is reserved for bounded, repeatable tasks such as documentation and mechanical fixtures.
• Sol is used for ambiguous, security-critical design and final review.

GPT-5.6 is not treated as a production security boundary. The demo’s scan results and remediation verification remain deterministic, testable, and reproducible.

Challenges

The hardest challenge was resisting the temptation to execute or install scanned code. Production Lens treats every repository instruction, comment, and source file as hostile data. Another challenge was defining honest evidence states: detecting a control is not the same as proving it works, and a Markdown claim cannot override contradictory code.

Remediation also required more than changing one line. A fix is only considered successful when the original finding disappears, unrelated findings remain stable, no new issue is introduced, tests pass, approval is recorded, and reset restores the exact original state.

Accomplishments

• A complete scan → evidence → remediation approval → rescan → comparison → reset workflow
• Eleven deterministic enterprise findings and seven evaluated injection findings
• Exact line evidence, secret redaction, and principle mapping
• Deterministic remediation for every bundled finding
• Production Lens self-scan and release-blocking adversarial tests
• A private live deployment judges can use without rebuilding
• A security design that keeps scanned content inert and capability-bounded

What I learned

Production readiness is not a score. It is current evidence that accountable people own the system, behavior has been proved, blast radius is contained, consequential actions are traceable and reversible, and no uncontrolled component holds private data, untrusted content, and external action authority at the same time.

What is next

The next milestone is deployment-backed private ZIP quarantine, real malware and secret scanning, shared authorization and admission state, durable audit delivery, and expanded adversarial evaluation. GPT-assisted repository analysis comes only after those boundaries are proven.## Inspiration

Judge testing instructions

Open https://production-lens.karunaker-molugu.chatgpt.site and sign in with ChatGPT if prompted.

1. Select Scan sample project and confirm 11 findings.
2. Open Customer records may be written to application logs.
3. Review its evidence and choose Review remediation options.
4. Check the approval box and apply the recommended fix.
5. Confirm the comparison shows 11 → 10 with no new finding.
6. Reset and confirm the baseline returns to 11.
7. Return home and scan the Security Test Agent to inspect seven injection findings.

Developer-tool installation and platform answer

Production Lens runs on Node.js 22.13+ with npm on macOS, Linux, or Windows. Run npm install, then npm run dev, and open http://localhost:3000. Run npm run security:check for the full test, audit, build, and production-server E2E gate. Judges can use the live private demo without rebuilding.

Built With

• cloudflare
• codex
• gpt-5.6
• next.js
• node.js
• react
• typescript
• vinext