Programming Languages by Industry: Security Implications in 2026

No authoritative public dataset measures which programming languages each industry uses. What you can measure is what each industry's regulators now demand of the software it ships: an SBOM for medical devices, a component inventory for payment software, vulnerability reporting under the EU Cyber Resilience Act, and audited update management for cars. Those demands, not language rankings, should shape your programme.

Plenty of articles say banks run Java and COBOL, carmakers run C and startups run TypeScript. Some of that is probably true; almost none of it is measured. This post separates what is measured (indexes, surveys, a federal audit, vendor data, regulatory text) from what is indicative, labels every claim with its source and date, and ends with what each industry should prioritise.

Key takeaways

• No one measures language share by industry. TIOBE counts search hits, the IEEE Spectrum Jobs ranking reads job postings, and the 2025 Stack Overflow survey publishes no industry breakdown. Any "finance uses X percent Java" figure is an estimate.
• Regulation is language neutral, not composition neutral. The FDA, PCI DSS v4.0.1, the EU Cyber Resilience Act and UN R155 never name a language. All require you to know what is inside your software and to fix it on a clock.
• Memory safety is where guidance names languages. CISA and the FBI call new critical infrastructure product lines in C or C++ a bad practice when memory safe alternatives exist, and asked for memory safety roadmaps by the end of 2025.
• Legacy code is measured only in government. GAO found 8 of the 11 most critical federal legacy systems use legacy languages, aged 23 to 60 years (July 2025).
• US federal attestation is no longer mandatory. OMB memo M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16, but kept the inventory duty and allows SBOM on request.
• Runtime end of life is the most predictable risk. Python 3.10 ended on 1 October 2026; .NET 8 and .NET 9 end on 10 November 2026; PHP 8.2 security support ends 31 December 2026.

Is there any data on programming languages by industry?

Short answer: not in a form you can cite as a share. We checked the three most quoted public sources and the most recent federal audit of legacy code, and none splits language use by industry.

What the language indexes actually measure

The TIOBE Index for October 2026 ranks Python first at 19.23 percent, followed by C at 11.33 percent, C++ at 8.87 percent and Java at 8.41 percent. TIOBE states that the index is built from search engine hits for programming related queries and is updated monthly. It tells you how much a language is talked about online. It does not tell you who writes it or where.

IEEE Spectrum's Top Programming Languages 2025 (23 September 2025, Stephen Cass) has a Jobs ranking based only on what employers ask for. Python moved to first, up from second in 2024, and the article calls SQL a skill that remains very valuable. Spectrum's most recent methodology page we could read (29 August 2023) names the IEEE Job Site and CareerBuilder as job posting sources. It is the closest public proxy for commercial demand, but it is one ranking for all employers, with no industry cut.

The 2025 Stack Overflow Developer Survey had 31,771 answers to its language question, 24,759 from professional developers. Its "Work" page reports company size from 28,488 answers but publishes no industry question. A large IDE maker's 2025 ecosystem report refused automated access, so we left it out rather than quote it second hand.

Table 1: the same languages across two indexes

Here is how the languages most often associated with regulated industries look in the two broadest datasets. The gap between the columns is itself informative: TIOBE rewards languages people search about, Stack Overflow rewards languages active community members use.

Sources: TIOBE Index, October 2026; Stack Overflow Developer Survey 2025, technology section. The right hand column is our indicative label, not a measured split.

Two disagreements stand out. COBOL sits at 16th in TIOBE but is used by under 1 percent of surveyed professional developers. Visual Basic sits 7th in TIOBE, ahead of SQL, while VBA is used by 3.3 percent of surveyed professionals. Neither dataset is wrong. They measure different things, and the industries that run the most COBOL and Visual Basic are the least likely to be represented in a developer community survey.

Why does TIOBE still rank Visual Basic 7th?

TIOBE does not publish which search queries feed each language, so any explanation is inference. Ours is this: "Visual Basic" in search traffic covers decades of desktop applications, Office macros and Access databases that still run inside finance, insurance, accounting and operations teams. Those authors are often analysts, not software engineers, which is why the language shows up in search volume but barely registers in developer surveys. The security implication is real either way: macro based tools often sit outside the software inventory entirely, and nothing in a package manager will tell you they exist.

Where does legacy code concentrate?

The one industry where legacy language use is measured rather than assumed is US federal government. The GAO report "Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems" (GAO-25-107795, released 17 July 2025) is the best public evidence available.

Table 2: GAO's findings on critical federal legacy systems

Old language plus unsupported platform plus known vulnerabilities is the real legacy risk. COBOL is not insecure as a language; the toolchain and middleware stop receiving fixes and the people who could patch them retire. For banking and insurance we found no public dataset measuring COBOL share with the same rigour, so treat claims about how much banking runs on COBOL as unverified unless they cite a study you can read. We go deeper on what modernising those systems means for supply chain risk in legacy COBOL and supply chain modernisation.

Which industries carry the most C and C++?

Again, nobody publishes a share. But two kinds of evidence point the same way.

First, the standards. The MISRA Consortium calls MISRA C "the de facto standard" for C where safety, security and code quality matter, and says it began as guidance for road vehicle electronics. A coding standard only becomes a de facto requirement where an industry writes a lot of the language.

Second, guidance aimed at those sectors. CISA and the FBI's "Product Security Bad Practices" (version 2.0, 17 January 2025) calls new critical infrastructure product lines in memory unsafe languages such as C or C++ risky when memory safe alternatives are readily available, and asks for a memory safety roadmap for existing products by the end of 2025. CISA and NSA followed with "Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development" on 24 June 2025.

On that evidence, the most memory safety exposure sits in automotive, medical devices, industrial control and anything else that ships firmware, which are also the most heavily regulated product sectors.

What the data says about memory safety in one large C and C++ codebase

The best public measurement of what changes when a C and C++ heavy codebase shifts new code to a memory safe language comes from Android. Google published updated figures on 13 November 2025.

Table 3: Android memory safety figures, 2025

Google notes that the Rust density figure rests on one near miss in roughly 5 million lines, so it calls the estimate conservative. One codebase is not an industry. But it is the strongest public evidence that memory safety exposure tracks the language of new code, and it is the reason regulators now ask for roadmaps. Our CISA memory safe languages roadmap post covers the roadmap guidance in more depth.

Which regulations push language or composition choices per industry?

This part is measurable because the text is public. Apart from the CISA guidance above, none names a language. All require you to know what is in your software.

Healthcare and medical devices: FDA section 524B

Section 524B of the Federal Food, Drug, and Cosmetic Act was added by the Consolidated Appropriations Act, 2023, signed on 29 December 2022. According to the FDA's cybersecurity FAQ, it applies to premarket submissions made on or after 29 March 2023 for "cyber devices": devices that include software the sponsor validated, installed or authorised, that can connect to the internet, and that have characteristics that could be vulnerable to cybersecurity threats.

Sponsors must include three things: a plan to monitor, identify and address postmarket vulnerabilities and exploits, including coordinated vulnerability disclosure; processes that give reasonable assurance the device is cybersecure, with postmarket updates and patches; and, in the FDA's words, an SBOM "for the commercial, open-source, and off-the-shelf software components." The FDA's refuse to accept transition ended on 1 October 2023.

The FDA's current guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," is dated February 2026 and supersedes the 27 June 2025 final guidance.

A firmware team writing C with vendored libraries has the same SBOM duty as a team shipping Python with hundreds of PyPI packages, and often finds it harder because vendored code has no lockfile.

Payments and finance: PCI DSS v4.0.1 requirement 6.3.2

PCI DSS v4.0.1 requirement 6.3.2 calls for an inventory of bespoke and custom software, and of the third party software components incorporated into it, maintained to support vulnerability and patch management. It was one of 51 future dated requirements that became mandatory on 31 March 2025, according to a QSA firm's January 2026 explainer. One secondary table we saw in search results lists 1 April 2025 instead; the 31 March date is the one most sources use.

PCI DSS does not prescribe SBOM formats or fields. In practice, assessors compare your software documentation against the inventory and check that the inventory is actually used to drive patching. An SBOM that is generated and never read does not meet the intent.

It reaches every language in the cardholder data environment: Java or C# services, payment page JavaScript, and Python or VBA tools that touch card data.

Products sold in the EU: the Cyber Resilience Act

The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. The European Commission's page gives two application dates: reporting obligations from 11 September 2026, and the main obligations from 11 December 2027. From 11 September 2026, manufacturers must report actively exploited vulnerabilities, and the Commission notes that vulnerability handling applies across the product lifecycle.

The regulation text, as widely summarised, requires manufacturers to identify and document components, including an SBOM in a commonly used, machine readable format covering at least top level dependencies (Annex I, Part II), and sets a default support period of at least five years unless the product's expected use is shorter. Secondary sources describe a 24 hour early warning and 72 hour notification for actively exploited vulnerabilities. We could not load the Official Journal text directly during research, so confirm article numbers against EUR-Lex before citing them in a contract.

It reaches every industry selling software or connected hardware into the EU.

Automotive: UN R155, UN R156 and ISO/SAE 21434

The UK Vehicle Certification Agency's page (updated 22 May 2026) gives the clearest public summary. UN R155 requires a cybersecurity management system (CSMS) and maps closely to ISO 21434. UN R156 requires a software update management system (SUMS), with ISO 24089 as the closest standard. Both are audit based.

For EU unlimited series vehicles, R155 applied to new whole vehicle type approvals from 6 July 2022 and to existing type approvals from 7 July 2024. R156 applied to new whole vehicle type approvals from 7 July 2024, to new complete vehicles from 7 July 2026, and to new completed vehicles from 7 July 2029.

Only manufacturers can obtain R155 approval, but they must show they manage supply chain risk by cascading security requirements to suppliers, often by contract, with ISO 21434 clause 7 on distributed cybersecurity activities as the reference. That is how an R155 obligation turns into a component inventory request on a tier 2 supplier's C codebase.

US federal: secure software attestation is now optional

This is the regulation that changed most in 2026, and many briefs have not caught up.

CISA released the Secure Software Development Attestation Form on 11 March 2024 under OMB memos M-22-18 and M-23-16, built on the NIST Secure Software Development Framework (SP 800-218, version 1.1, February 2022). On 23 January 2026, OMB memo M-26-05, "Adopting a Risk-based Approach to Software and Hardware Security," rescinded both M-22-18 and M-23-16. The memo describes M-22-18 as imposing "unproven and burdensome software accounting processes."

What remains matters more than what went. Under M-26-05, agencies "shall continue to maintain a complete inventory of software and hardware" and build assurance processes that match their risk. Agencies may still use the attestation form, and may adopt contract terms that require a producer to provide a current SBOM on request. For cloud platforms, the memo says that SBOM should cover the runtime production environment. It points agencies to SP 800-218, to CISA's 2025 SBOM minimum elements (published in draft on 22 August 2025) and to CISA's hardware bill of materials framework.

The federal requirement moved from one mandatory form to agency by agency contract terms, which usually means more variety in what suppliers are asked for.

Table 4: regulatory pressure by industry

Only the last row names a language, and it is guidance, not law. Every row requires composition knowledge.

Typical stacks by industry (indicative, not measured)

Because the split cannot be sourced as a share, each line below carries an evidence label. Read it as a hypothesis, never as data.

If you need this split for a board paper, produce it from your own SBOMs by counting components by ecosystem across your estate.

How does ecosystem risk map to each industry's stack?

The language bites through the package ecosystem and build model around it, not through the language itself.

Package manager ecosystems (npm, PyPI, Maven, NuGet, Go modules, Cargo). SaaS, fintech front ends and data teams sit here. The risk is volume and depth: large transitive trees and a constant flow of advisories. Lockfiles make a complete inventory cheap, so the bottleneck is triage and fix throughput, not visibility.

C and C++ with vendored or system libraries. Automotive, medical devices and industrial firmware sit here. Third party code is often copied into the tree and shipped inside a binary with no package manager, so an SBOM must be assembled from build files, vendor manifests and binary analysis. Memory safety bugs add severity. The bottleneck is visibility.

Legacy runtimes (COBOL, Visual Basic, old Java). Government, banking cores and insurance sit here. The risk is the platform; GAO's finding that 4 of 11 critical systems lack supported hardware or software is the measured version. The bottleneck is end of life management.

Most large regulated organisations run all three at once, which is why programmes should be built from the inventory up, not from an industry stereotype down. Our posts on SBOM adoption across industries and mean time to remediate by company size and industry add the numbers.

Which runtime end of life dates hit each industry hardest?

End of life dates are the most predictable risk on this list, and they cluster in the next few months. All dates below come from the projects' own support pages, read on 23 October 2026.

Table 5: runtime end of life dates in the next 15 months

Ranked: days of support left from 23 October 2026

Day counts are our arithmetic from the dates on each project's support page. Python 3.11 is left out because its October 2027 date is scheduled by month, not day.

.NET 8 is the date to watch. It is a long term support release, the kind of version enterprise teams tend to standardise on, and it leaves support on the same day as .NET 9. Microsoft's policy gives LTS releases three years and STS releases two years. .NET 10, supported until 14 November 2028, is the target. On Node.js, the project's releases page lists version 20 as end of life and versions 22 and 24 as LTS; production systems should run only Active or Maintenance LTS lines.

Java is left out on purpose: its support dates depend on the JDK distribution, so record the distribution as well as the version. For regulated teams, a runtime that can no longer be patched also undermines the CRA's support period, PCI patching and the FDA's postmarket plan.

A language risk profile for each industry

For each industry: the dominant composition risk, the regulatory driver and what to fix first. The risk column builds on indicative stacks, so confirm it against your own inventory.

What should each industry prioritise in its security programme?

Banking and payments. Assessors test requirement 6.3.2 by comparing documentation to the inventory. The common gap is an inventory that covers Java services but misses payment page scripts, Python reconciliation jobs and finance VBA. Make the inventory the source of patch work, not a parallel spreadsheet.

Healthcare and medical devices. For firmware, record the upstream project, version and local patches of every vendored library when it enters the tree. For clinical software, .NET 8 end of support on 10 November 2026 is the nearest hard date.

Automotive. R155 audits look at supplier risk: receive supplier SBOMs, check them against vulnerability data and compare them across releases. New components are where a memory safety roadmap pays off fastest.

US federal suppliers. M-26-05 removed a form, not the inventory duty. Contracts can still require an SBOM on request, and SSDF evidence stays useful.

Critical infrastructure. Without a published memory safety roadmap, you are past the date CISA and the FBI set. A roadmap can start with new components and exposed parsers rather than a rewrite.

SaaS. Easy to inventory, hard to keep current. Automate upgrade pull requests, gate merges on policy and track runtime end of life like CVEs.

Where Safeguard fits

Safeguard scans repositories, container images and SBOM files, builds a transitive inventory across npm, PyPI, Maven and Gradle, Go, Cargo, NuGet, Composer and Bundler plus container layers, and exports SPDX and CycloneDX. The platform shows which projects contain a given component and version. Reachability analysis ranks findings by whether your code calls the vulnerable path, and policies and gates act on them in the platform and in CI. The compliance suite maps evidence to frameworks including the NIST SSDF.

Where it does not help: it does not inventory COBOL on a mainframe or spreadsheet macros, vendored C and C++ without a manifest needs build level work first, and it does not file your FDA submission, CRA reports or R155 audit.

Step by step: build the inventory every regulator asks for

These steps produce an inventory you can hand to a PCI assessor, attach to an FDA submission or supply to an agency on request.

1. Generate SBOMs from the ecosystems you already use.

# npm (built into npm 9 and later)
npm sbom --sbom-format cyclonedx > sbom-npm.cdx.json

# Maven, with the CycloneDX plugin
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

# Python, from the installed environment (CycloneDX Python tool)
pip install cyclonedx-bom
cyclonedx-py environment > sbom-python.cdx.json

# Go: list module versions compiled into a binary
go version -m ./bin/service

# .NET: list vulnerable packages including transitive ones
dotnet list package --vulnerable --include-transitive

2. Check runtime versions against end of life dates.

python3 --version
node --version
dotnet --list-runtimes
php -v
java -version

Record the JDK distribution as well as the version. Anything at or past the dates in Table 5 goes on a migration list with an owner and a date.

3. Scan the repository, the image and any supplier SBOMs with Safeguard.

# a repository
safeguard scan --dir .

# a built container image
safeguard scan --image registry.example.com/payments-api:1.42.0

# an SBOM a supplier sent you
safeguard scan --sbom supplier-ecu-firmware.cdx.json

Results are written as JSON under ./output, so they can be archived as audit evidence alongside the build.

4. Capture vendored C and C++ code by hand where no manifest exists. For each vendored directory, record the upstream project, the exact version or commit, the licence and any local patches. Commit that record next to the code so the next build can include it in the SBOM.

5. Gate merges in CI. A minimal GitHub Actions job that fails the build when the SBOM step fails, so an inventory gap blocks release:

name: sbom
on: [pull_request]
jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 24
      - run: npm ci
      - run: npm sbom --sbom-format cyclonedx > sbom.cdx.json
      - uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.cdx.json

Add your vulnerability gate after the SBOM step. Safeguard policies and gates can block, warn, notify or require approval at that checkpoint.

6. Keep the inventory alive. Rebuild SBOMs on every release, compare them with the previous one, and treat a new component or a downgrade as a review item.

How we measured

• Language data. TIOBE Index (October 2026 edition, read 23 October 2026); IEEE Spectrum Top Programming Languages 2025 and its latest readable methodology page (2023); Stack Overflow Developer Survey 2025 technology and work sections, using the professional developer column where given. A large IDE maker's 2025 report refused automated access and is excluded.
• Industry split. None of these sources publishes language use by industry. Every industry label is marked indicative with its evidence stated. We did not scrape job boards or classify engineering blogs; a hand built sample would be too small to publish as a share.
• Legacy and memory safety. GAO-25-107795 (17 July 2025) for federal legacy systems; Google's 13 November 2025 Android post for Table 3, which covers one codebase.
• Regulation. FDA cybersecurity FAQ and February 2026 guidance page; European Commission CRA page; UK VCA R155 and R156 page (22 May 2026); CISA attestation form page; OMB memoranda index and the text of M-26-05; NIST SP 800-218; CISA 2025 SBOM minimum elements page; CISA and FBI Product Security Bad Practices v2.0. PCI DSS 6.3.2 comes from a QSA firm's January 2026 explainer, because the standard is a licensed PDF. CRA article level detail could not be loaded from EUR-Lex and is flagged in the text.
• End of life. python.org, nodejs.org, Microsoft's .NET policy and php.net, read 23 October 2026; day counts are our arithmetic.

Where datasets disagree, we report both figures and explain the difference rather than averaging.

Common mistakes

• Treating an index rank as an industry fact. TIOBE ranking Visual Basic 7th says nothing about how much your bank runs.
• Waiting for a language specific rule. None of the FDA, PCI, CRA or UNECE texts names a language; the composition duty already applies.
• Missing the edges. Payment page scripts, notebooks, build tools and spreadsheet macros touch regulated data and are routinely left out.
• Generating an SBOM once. Every regulator here cares whether the inventory drives patching.
• Reading M-26-05 as deregulation. It removed a mandatory form, not the inventory duty.
• Ignoring vendored C and C++. Code copied in without a manifest is where the oldest vulnerabilities hide.
• Tracking CVEs but not runtimes. .NET 8, Python 3.10 and PHP 8.2 all leave support within weeks of each other.

FAQ

Which programming language is most used in banking?

No public dataset measures it. Banking is commonly associated with COBOL in core systems and Java or C# in services, but that is an industry assumption, not a measured share. The only reliable answer for your bank comes from SBOMs and runtime inventories across your own estate.

Does PCI DSS 4.0 require an SBOM?

Not by name. Requirement 6.3.2 in PCI DSS v4.0.1 requires an inventory of bespoke and custom software and its third party components, used to manage vulnerabilities and patches. It became mandatory on 31 March 2025. An SBOM is the most common way to meet it, but the standard does not prescribe a format.

Does the FDA require an SBOM for medical devices?

Yes, for cyber devices. Section 524B of the FD&C Act requires premarket submissions made on or after 29 March 2023 to include an SBOM for commercial, open source and off the shelf software components, along with a postmarket vulnerability plan and a patching process.

Is the US federal secure software attestation form still required?

No longer as a blanket requirement. OMB memo M-26-05 of 23 January 2026 rescinded M-22-18 and M-23-16. Agencies may still choose to use the form, must keep a complete software and hardware inventory, and may require a current SBOM on request through contract terms.

When does the EU Cyber Resilience Act apply?

It entered into force on 10 December 2024. Reporting of actively exploited vulnerabilities applies from 11 September 2026, and the main obligations apply from 11 December 2027, according to the European Commission. The SBOM requirement sits in Annex I of the regulation and falls under the main obligations.

Do automotive regulations require memory safe languages?

No. UN R155 and R156 require a cybersecurity management system and a software update management system, and ISO/SAE 21434 sets out engineering processes. None mandates a language. Memory safety pressure comes from CISA and FBI guidance and from coding standards such as MISRA C and MISRA C++.

Why is COBOL still in the TIOBE top 20?

TIOBE counts search engine hits, and COBOL remains in active use in government, banking and insurance systems that need maintenance. GAO found that 8 of the 11 most critical US federal legacy systems use legacy languages, and both Treasury systems on that list run COBOL and Assembly.

Which industries have the most memory safety risk?

On the available evidence, industries that ship firmware and embedded software in C and C++: automotive, medical devices, industrial control and telecoms equipment. Google reported that memory safety issues fell below 20 percent of Android vulnerabilities in 2025 as new code moved to Rust, which shows how strongly the language of new code drives this risk.

Fix it without waiting for upstream

Every regulation here asks the same follow up question once you have an inventory: how fast do you fix what it shows?

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

You can install the CLI from safeguard.sh/download and read the CLI documentation.

This first demo is a real CLI session. You ask the assistant to fix the lodash CVE in a repository; it reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. For a regulated team, approval at every step makes the change reviewable evidence.

Click through it at your own pace, or open it full screen.

This demo sets up the runner on your own machine, approves it with its device code, then scans from the terminal. It suits a device maker or federal supplier that wants scans to run inside its own boundary.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and shows you choosing which tools Claude can use. When an auditor asks which products contain a component, a security lead can ask in plain language.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• TIOBE Index, October 2026
• IEEE Spectrum, The Top Programming Languages 2025
• IEEE Spectrum, Top Programming Languages methodology
• Stack Overflow Developer Survey 2025, Technology
• Stack Overflow Developer Survey 2025, Work
• GAO-25-107795, Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems
• Google, Rust in Android: move fast and fix things (13 November 2025)
• MISRA
• CISA and FBI, Product Security Bad Practices
• CISA and NSA, Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development
• FDA, Cybersecurity in Medical Devices Frequently Asked Questions
• FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions
• HALOCK, What is the new PCI DSS v4.0.1 software catalog mandate
• European Commission, Cyber Resilience Act
• Regulation (EU) 2024/2847 on EUR-Lex
• UK Vehicle Certification Agency, Cyber Security and Software Updating
• CISA, Secure Software Development Attestation Form
• OMB memoranda index
• OMB M-26-05, Adopting a Risk-based Approach to Software and Hardware Security
• NIST SP 800-218, Secure Software Development Framework v1.1
• CISA, 2025 Minimum Elements for a Software Bill of Materials
• Python developer guide, status of Python versions
• Node.js, previous releases
• Microsoft, .NET and .NET Core support policy
• PHP, supported versions

Last reviewed: 23 October 2026. Regulations, indexes and support dates change; check the linked sources for the latest status.