Open-source security is posing challenges governments can’t easily solve

An epidemic of cyberattacks on open-source software has mounted in recent months, making clear how uniquely difficult it is to protect the publicly available code, from both a policy and a technical perspective, that serves as the foundation for so much of the digital world.

While open-source software security got a boost in attention under President Joe Biden — whose administration grappled with the fallout from the potentially catastrophic Log4j flaw that emerged in 2021 — a number of open-source experts say that government protection efforts have suffered setbacks under President Donald Trump. Many also say companies that heavily rely on open-source software, which is basically all of them, haven’t shouldered enough of the responsibility for safeguarding it.

“What we’re seeing is years of lack of investment sustainment in open-source software that is finally starting to catch up to us, where it seems like every week there’s a new supply chain compromise,” said Jack Cable, who held a role at the Cybersecurity and Infrastructure Security Agency where he worked on open-source security before departing under Trump.

The advancements of frontier artificial intelligence models stand to exacerbate the risk further, while simultaneously illustrating what makes defending open source difficult: Project Glasswing said shortly after its announcement that it had uncovered 6,202 high- or critical-severity vulnerabilities in a scan of more than 1,000 open-source projects, but that it had disclosed only 502 of them to open-source project maintainers and only 75 had been patched as of May 22 (albeit some due to typical patching lagtimes).

At the same time, there are questions about how much the government can help, even as overseas governments seek to focus on open-source security.

The evolution of open-source risk 

There are a series of factors contributing to the current threat to open-source software, experts say.

One is simply that attackers go to the area where they can get the highest return on their work. Compromising open-source software gives them the chance to get into the supply chain and exploit additional targets.

“Twenty years ago, open source was still fairly niche,” said Æva Black, who also worked on open-source security at CISA but left when Trump came back into power. “The potential blast radius if you managed to compromise open source was relatively small, because back then the world didn’t run on open source. Now almost everything runs on open source,” she said, from modern cars to satellites.

Another part is the nature of open-source software itself.

“It’s a symptom [of having] lots of open source [that] is a little bit under-maintained or not cared for enough, so that we spend too little effort and money and infrastructure on them,” said Daniel Stenberg, who is the creator and maintainer of cURL, a popular open-source project. “Lots of open source is being maintained by small teams, lots of volunteers, and I think that that’s a tough situation.”

That doesn’t mean the maintainers are to blame, Stenberg said. The companies that rely on open-source need to be diligent about using it, Black said.

“What we’re seeing in that realm right now is not new; it is more advanced and far more widespread,” she said. “The problem remains that companies who use open source — because open source is by far the most efficient way to collaborate on non-product value features — most companies are not implementing a responsible and safe utilization pathway.”

Open-source projects lack a systematic way to handle coordinated vulnerability disclosures, unlike companies or industry groups with formal processes, said Dan Lorenc, CEO and co-founder of Chainguard. Project maintainers sometimes aren’t reachable, and those who are available are flooded with reports, many of them unverified findings from AI tools that waste their time without adding value..

Of course, some of those vulnerability reports turn out to be legitimate. “Mythos and AI models have contributed to an uptick in the number of vulnerabilities and things that we’re able to find” in open-source software, said Alex Zenia, chief technology officer for the cybersecurity company Edera.

All of that leaves more room for companies, non-profits and world governments to improve open-source security.

A moment of momentum

While open-source software security isn’t a new issue, the 2021 discovery of the Log4j flaw sounded alarms within the cybersecurity community. Jen Easterly, then the director of CISA, called it “one of the most serious I’ve seen in my entire career, if not the most serious,” with the potential to affect hundreds of millions of devices given the ubiquitous nature of the popular open-source logging library.

A year later, the Cyber Safety Review Board released its report on the incident, concluding that swift action from industry and government averted a disaster. But the incident “called attention to security risks unique to the thinly-resourced, volunteer-based open source community,” it wrote. “This community is not adequately resourced to ensure that code is developed pursuant to industry-recognized secure coding practices and audited by experts.”

The U.S. government actions after included some steps focused specifically on open-source software such as creation of the Open-Source Software Security Initiative and hires of well-regarded open-source security experts at CISA such as Black, but also some steps that could be applied more generally and still help with open-source security, such as greater promotion of secure-by-design, memory-safe languages and software bills of materials (SBOMs).

Some of the Biden administration work on open-source security started before Log4j, such as provisions from an executive order he issued in 2021 that directed CISA along with the Office of Management and Budget and General Services Administration to issue guidance to agencies. 

The administration’s 2023 cybersecurity strategy also stepped into the long, thorny discussions over software liability, with a mention of open-source security: “Responsibility must be placed on the stakeholders most capable of taking action to prevent bad outcomes, not on the end-users that often bear the consequences of insecure software nor on the open-source developer of a component that is integrated into a commercial product.“ The Biden administration always indicated that addressing software liability would take a prolonged battle ahead.

Under Trump, many of the Biden administration’s efforts have languished. CISA’s splashy hires on open-source are gone, including Black, Tim Pepper and Anjana Rajan. Also departed are leading figures on secure-by-design and SBOMs, with CISA personnel cutbacks slicing deep. 

No one has seen any sign that the national cyber director-led Open-Source Software Security Initiative is active, with few participants remaining in government today. The Trump administration cyber strategy doesn’t mention open-source.

“The loss of open-source experts at CISA “is unfortunate, and it will be hard for the government to try to rebuild capacity, but I do think now more than ever CISA has a core role to play to secure open source software,” Cable said.

The pressure is mounting

It’s not that the issue is getting zero attention from those in a position to make a difference. Nick Andersen, the acting director of CISA, said last month that open-source security was an area of particular concern for him.

Andersen responded to concerns about CISA staffing levels on open-source security and spoke more broadly on the topic in a statement to CyberScoop.

“As artificial intelligence and other technologies have the power to transform how vulnerabilities are discovered and exploited, CISA recognizes that the open source software (OSS) that underpins much of the nation’s critical infrastructure will need to be hardened,” he said. “CISA actively collaborates with our partners on shared priorities, including OSS security, to ensure time and resources are spent where they matter the most.  We have an immensely talented team, but are also accelerating our hiring in critical areas, to strengthen the nation’s defenses against cyber threats.”

The Office of the National Cyber Director did not respond to requests for comment.

There’s been some activity on Capitol Hill, too. The Securing Open Source Software Act, which Cable worked on during a stint as a Senate staffer, would direct CISA and other agencies to take actions to mitigate open-source software security risks, but the legislation has stalled since its introduction in 2022. A portion of the bill, however, was included in the Department of Homeland Security funding law Trump signed in April, directing CISA to brief Congress on the value of establishing something like an open source program office, which some companies use to manage open source within a given firm.

Senate Intelligence Committee Chairman Tom Cotton, R-Ark., has pushed the executive branch to improve its awareness of foreign adversaries playing roles in open-source software used by national security-focused agencies.

The annual defense policy bill in the House calls on the Defense Department’s chief information officer to report to Congress on a plan to secure open-source software supply chains, saying lawmakers are “concerned that the Department lacks sufficient visibility into the origins, maintenance, and security of OSS applications and software dependencies.”

That defense authorization bill language is “really beneficial, and I think it signals acknowledgement of this changing of culture” around open-source security risks, said Hayden Smith, founder of HuntedLabs, whose company won a contract with the Space Development Agency on supply chain security — agency work that the defense bill singled out.

“The report language is the first time the Hill is trying to get a true handle on foreign influence in open source code where they have oversight,” he said, saying it was a “piece of the puzzle” along with Cotton’s letter and a memo from Secretary of Defense Pete Hegseth last year about foreign influence in the Pentagon supply chain. “It’s good and would trickle down into everyone who provides software to the department.”

Zenia, though, believes trying to isolate China from open-source systems isn’t in and of itself a good idea. 

“I don’t think that that makes a lot of sense, because they’re actually pretty good things that people contribute to open source,” she said. “Not everyone is malicious, and what are we going to do, spy on every single open source maintainer?” It’s more about doing things like making sure that highly-classified systems are set up in a separate way, she said.

Europe is also taking action to secure open-source software that the United States doesn’t seem ready or willing to do right now. Germany, for instance, devotes grants to the security of open-source projects, although Stenberg pointed out that sometimes money doesn’t equate to maintainers being able to fix flaws more quickly, depending on the project’s size.

The Cyber Resilience Act (CRA) adopted by the Council of the European Union in 2024 could offer another road on open-source security. The CRA requires those who use open-source software products as part of any commercial activity to take certain security measures. 

Black said that when she was at CISA, there were discussions between the agency and European counterparts about finding compatible ideas on open-source security, but that momentum died with the Trump administration.

But “Europe kept rolling, and now has in place a new legal framework that is set to really reshape open-source security for potentially the whole world, but certainly for anyone who wants to work with Europe on open source,” she said.

Lorenc recently wrote that “open source isn’t governable.” He said an organization like a neutral nonprofit, possibly using some government funding, should take responsibility for things like coordinating vulnerability disclosure into one pipeline. He also said there needs to be one authority in charge of “forking” — that is, taking a project and assigning stewardship elsewhere — when a maintainer isn’t responsive to vulnerabilities. 

There are differing opinions on how much past government warnings, advisories and guidance have helped. Smith gave some credit to government agencies that “have all responded to open source attacks using the means they have.”

Stenberg said that “I don’t think they make any big dent at all in the big scheme of things.” They might get some attention initially, “then two years later we all forgot about them, and they actually didn’t change much.”

Ideally, everyone could get on the same page, Zenia said. “The best way to do this is if people actually collaborated on a global scale on some sort of regulation around this, but that seems nearly impossible at the current moment,” she said. (The United Nations’ Open Source Week runs all this week.)

But if there’s an upside to the spate of attacks on open-source software, it’s the energy it gives to how better to secure it, Lorenc said, invoking the political saying to never let a good crisis go to waste.

“Everyone knows the industry has to change,” he said. “This is a really good crisis, and the right things are happening in the right places, and organizations are rethinking their culture around software development, and they know what they have to do. It’s just something that’s never been top of the priority list for the last 10 years. Now it is, and they’re doing it, and it’s, ‘Can we do it fast enough?’”

Tim Starks

Written by Tim Starks

Tim Starks is senior reporter at CyberScoop. His previous stops include working at The Washington Post, POLITICO and Congressional Quarterly. An Evansville, Ind. native, he’s covered cybersecurity since 2003. Email Tim here: tim.starks@cyberscoop.com.

Claude Security Plugin, Azure Priv-Esc, Kali365 MFA Bypass, FIFA Scams +15 More – CYBERDEFENSA.MX

Every time you think the industry has finally stopped doing some reckless, low-effort crap, somebody spins up a fresh box full of sketchy loaders, fake installers, recycled social-engineering bait, and enough exposed infrastructure to make you wonder if prod is just a public beta now – meanwhile some researcher casually drops a technique that turns a «minor» foothold into total account compromise because apparently six digits and blind trust were all that stood between your vault and getting absolutely pwned. Cool. Great. Love that for us.

Then there’s the supply chain mess… signed binaries, poisoned updates, legit tooling getting hijacked like it’s still 2017, plus a few reports this week that feel less like advanced tradecraft and more like watching skiddies discover low-hanging fruit with enterprise branding slapped on top. The weird part isn’t that it works. The weird part is how damn easy it still is.

Anyway. Grab caffeine. Let’s get into it.

None of this was especially sophisticated. That’s the lesson nobody wants to hear. Most breaches still start with trust abuse, stale configs, lazy access controls, or users getting socially engineered by someone sounding vaguely competent over the phone.

Patch faster. Audit harder. Stop assuming signed software, MFA prompts, or «internal-only» tooling means safe. The attackers already figured out the shortcuts. Might be time defenders stop pretending those shortcuts don’t exist.

Acciones de GitHub de Trivy Security Scanner violadas, 75 etiquetas secuestradas para robar secretos de CI/CD – CYBERDEFENSA.MX

Trivy, un popular escáner de vulnerabilidades de código abierto mantenido por Aqua Security, se vio comprometido por segunda vez en el lapso de un mes para entregar malware que robaba secretos confidenciales de CI/CD.

El último incidente afectó a GitHub Actions «aquasecurity/trivy-acción» y «aquasecurity/configuración-trivy«, que se utilizan para escanear imágenes del contenedor Docker en busca de vulnerabilidades y configurar el flujo de trabajo de GitHub Actions con una versión específica del escáner, respectivamente.

«Identificamos que un atacante forzó 75 de 76 etiquetas de versión en el repositorio aquasecurity/trivy-action, la acción oficial de GitHub para ejecutar análisis de vulnerabilidades de Trivy en canales de CI/CD», dijo el investigador de seguridad de Socket, Philipp Burckhardt. dicho. «Estas etiquetas se modificaron para servir una carga maliciosa, convirtiendo efectivamente las referencias de versiones confiables en un mecanismo de distribución para un ladrón de información».

La carga útil se ejecuta dentro de los ejecutores de GitHub Actions y tiene como objetivo extraer valiosos secretos de desarrollador de entornos CI/CD, como claves SSH, credenciales para proveedores de servicios en la nube, bases de datos, Git, configuraciones de Docker, tokens de Kubernetes y billeteras de criptomonedas.

Ciberseguridad

El desarrollo Marca el segundo incidente en la cadena de suministro que involucra a Trivy. Hacia finales de febrero y principios de marzo de 2026, un robot autónomo llamado hackerbot-claw aprovechó un flujo de trabajo «pull_request_target» para robar un token de acceso personal (PAT), que luego se utilizó como arma para tomar el control del repositorio de GitHub, eliminar varias versiones de lanzamiento y enviar dos versiones maliciosas de su extensión Visual Studio Code (VS Code) a Open VSX.

La primera señal del compromiso fue marcado por el investigador de seguridad Paul McCarty después de que se publicara una nueva versión comprometida (versión 0.69.4) en el repositorio de GitHub «aquasecurity/trivy». Desde entonces, la versión fraudulenta ha sido eliminada. De acuerdo a Fenómenola versión 0.69.4 inicia tanto el servicio legítimo Trivy como el código malicioso responsable de una serie de tareas:

  • Realice el robo de datos escaneando el sistema en busca de variables ambientales y credenciales, cifrando los datos y extrayéndolos a través de una solicitud HTTP POST a scan.aquasecurtiy[.]org.
  • Configurar la persistencia usando un servicio del sistema después de confirmar que se está ejecutando en una máquina de desarrollador. El servicio systemd está configurado para ejecutar un script Python («sysmon.py») que sondea un servidor externo para recuperar la carga útil y ejecutarla.

En un comunicado, Itay Shakury, vicepresidente de código abierto de Aqua Security, dicho los atacantes abusaron de una credencial comprometida para publicar versiones maliciosas de trivy, trivy-action y setup-trivy. En el caso de «aquasecurity/trivy-action», el adversario impulsó 75 etiquetas de versión para señalar las confirmaciones maliciosas que contienen la carga útil del robo de información de Python sin crear una nueva versión ni enviar a una rama, como es la práctica estándar. Se forzaron siete etiquetas de «aquasecurity/setup-trivy» de la misma manera.

«Entonces, en este caso, el atacante no necesitaba explotar Git», dijo Burckhardt a The Hacker News. «Tenían credenciales válidas con privilegios suficientes para enviar código y reescribir etiquetas, que es lo que permitió el envenenamiento de etiquetas que observamos. Lo que no está claro es la credencial exacta utilizada en este paso específico (por ejemplo, un PAT de mantenimiento frente a un token de automatización), pero ahora se entiende que la causa principal es el compromiso de credenciales transferido del incidente anterior».

El proveedor de seguridad también reconoció que el último ataque se debió a una contención incompleta del incidente del hackerbot-claw. «Rotamos secretos y tokens, pero el proceso no fue atómico y es posible que los atacantes hayan estado al tanto de los tokens actualizados», dijo Shakury. «Ahora estamos adoptando un enfoque más restrictivo y bloqueando todas las acciones automatizadas y cualquier token para eliminar completamente el problema».

El ladrón opera en tres etapas: recolecta variables de entorno de la memoria del proceso del ejecutor y del sistema de archivos, cifra los datos y los extrae al servidor controlado por el atacante («scan.aquasecurtiy[.]organización»).

Si el intento de exfiltración falla, se abusa de la propia cuenta de GitHub de la víctima para almacenar los datos robados en un repositorio público llamado «tpcp-docs» mediante el uso del INPUT_GITHUB_PAT capturado, una variable de entorno utilizada en GitHub Actions para pasar una PAT de GitHub para la autenticación con la API de GitHub.

Actualmente no se sabe quién está detrás del ataque, aunque hay indicios de que el actor de amenazas conocido como TeamPCP puede estar detrás. Esta evaluación se basa en el hecho de que el recolector de credenciales se autoidentifica como «ladrón de nubes de TeamPCP» en el código fuente. También conocido como DeadCatx3, PCPcat, PersyPCP, ShellForce y CipherForce, el grupo es conocido por actuar como una plataforma de cibercrimen nativa de la nube diseñada para violar la infraestructura moderna de la nube para facilitar el robo de datos y la extorsión.

Ciberseguridad

«Los objetivos de credenciales en esta carga útil son consistentes con el perfil más amplio de robo y monetización nativo de la nube del grupo», dijo Socket. «El fuerte énfasis en los pares de claves del validador de Solana y las billeteras de criptomonedas está menos documentado como un sello distintivo de TeamPCP, aunque se alinea con las motivaciones financieras conocidas del grupo. El autoetiquetado podría ser una bandera falsa, pero la superposición técnica con las herramientas anteriores de TeamPCP hace que la atribución genuina sea plausible».

Se recomienda a los usuarios que se aseguren de utilizar las últimas versiones seguras:

«Si sospecha que estaba ejecutando una versión comprometida, trate todos los secretos del canal como comprometidos y rótelos inmediatamente», dijo Shakury. Los pasos de mitigación adicionales incluyen bloquear el dominio de exfiltración y la dirección IP asociada (45.148.10[.]212) a nivel de red, y verificar las cuentas de GitHub en busca de repositorios llamados «tpcp-docs», lo que puede indicar una exfiltración exitosa a través del mecanismo de reserva.

«Fije las acciones de GitHub a hashes SHA completos, no a etiquetas de versión», dijo el investigador de Wiz, Rami McCarthy. «Las etiquetas de versión se pueden mover para señalar confirmaciones maliciosas, como se demuestra en este ataque».

(Esta es una historia en desarrollo. Vuelva a consultarla para obtener más detalles).

OpenAI Codex Security escaneó 1,2 millones de confirmaciones y encontró 10.561 problemas de alta gravedad – CYBERDEFENSA.MX

OpenAI comenzó a implementarse el viernes Seguridad del Códiceun agente de seguridad impulsado por inteligencia artificial (IA) diseñado para encontrar, validar y proponer soluciones a vulnerabilidades.

La función está disponible en una vista previa de la investigación para los clientes de ChatGPT Pro, Enterprise, Business y Edu a través de la web del Codex con uso gratuito durante el próximo mes.

«Crea un contexto profundo sobre su proyecto para identificar vulnerabilidades complejas que otras herramientas agentes pasan por alto, lo que muestra hallazgos de mayor confianza con correcciones que mejoran significativamente la seguridad de su sistema y le evitan el ruido de errores insignificantes», dijo la compañía. dicho.

Codex Security representa una evolución de Aardvark⁠, que OpenAI presentó en versión beta privada en octubre de 2025 como una forma para que los desarrolladores y equipos de seguridad detecten y corrijan vulnerabilidades de seguridad a escala.

Ciberseguridad

Durante los últimos 30 días, Codex Security ha escaneado más de 1,2 millones de confirmaciones en repositorios externos durante el transcurso de la versión beta, identificando 792 hallazgos críticos y 10,561 hallazgos de alta gravedad. Estos incluyen vulnerabilidades en varios proyectos de código abierto como OpenSSH⁠, GnuTLS⁠, GOGS⁠, Thorium⁠, libssh, PHP y Chromium, entre otros. Algunos de ellos se enumeran a continuación:

  • GnuPG-CVE-2026-24881, CVE-2026-24882
  • GnuTLS: CVE-2025-32988, CVE-2025-32989
  • GOGS-CVE-2025-64175, CVE-2026-25242
  • Torio – CVE-2025-35430, CVE-2025-35431, CVE-2025-35432, CVE-2025-35433, CVE-2025-35434, CVE-2025-35435, CVE-2025-35436

Según la empresa de inteligencia artificial, la última versión del agente de seguridad de aplicaciones aprovecha las capacidades de razonamiento de sus modelos de frontera y las combina con validación automatizada para minimizar el riesgo de falsos positivos y ofrecer soluciones prácticas.

Los escaneos de OpenAI en los mismos repositorios a lo largo del tiempo han demostrado una precisión cada vez mayor y una disminución de las tasas de falsos positivos, cayendo estas últimas en más del 50% en todos los repositorios.

En una declaración compartida con The Hacker News, OpenAI dijo que Codex Security está diseñado para mejorar la relación señal-ruido al conectar el descubrimiento de vulnerabilidades en el contexto del sistema y validar los hallazgos antes de mostrárselos a los usuarios.

Específicamente, el agente trabaja en tres pasos: analiza un repositorio para controlar la estructura del sistema relevante para la seguridad del proyecto y genera un modelo de amenaza editable que captura lo que hace y dónde está más expuesto.

Una vez creado el contexto del sistema, Codex Security lo utiliza como base para identificar vulnerabilidades y clasifica los hallazgos en función de su impacto en el mundo real. Los problemas marcados se someten a pruebas de presión en un entorno aislado para validarlos.

Ciberseguridad

«Cuando Codex Security se configura con un entorno adaptado a su proyecto, puede validar problemas potenciales directamente en el contexto del sistema en ejecución», dijo OpenAI. «Esa validación más profunda puede reducir aún más los falsos positivos y permitir la creación de pruebas de concepto funcionales, brindando a los equipos de seguridad evidencia más sólida y un camino más claro hacia la remediación».

La etapa final implica que el agente proponga las soluciones que mejor se alineen con el comportamiento del sistema para reducir las regresiones y hacerlas más fáciles de revisar e implementar.

Las noticias sobre Codex Security llegan semanas después de que Anthropic lanzara Claude Code Security para ayudar a los usuarios a escanear una base de código de software en busca de vulnerabilidades y sugerir parches.