Bring security to your AI stack.

Keep using the packages you depend on — securely.

Your AI stack runs on open source. When a vulnerability appears, you can’t always replace the package, rewrite your application, or wait for someone else to fix it.
OpenTeams brings accountability to the AI supply chain. We remediate critical vulnerabilities and secure the path software takes from source to production.

Where OpenTeams fits in your stack

Your AI applications

Models, data services, product features

AI packages

Remediation & secure build pipeline

Existing infrastructure security

Container security

Hardened, minimal images

Operating-system security

OS packaging & hardening

Your AI stack runs on these software stacks. Our engineers maintain the foundational AI software that you depend on.

And over 40 others.

AI security is now
supply-chain security.

The threat to an AI system rarely starts where you run it. It starts upstream, in the open-source packages your AI is built from, maintained by the kind of engineers you’ll work with here.

You can’t stop using a package just because it has a vulnerability. Your stack depends on it. So the real question isn’t is it safe to install? It’s how do we fix this and keep using it?

There are two ways your stack gets compromised.

01

Vulnerabilities in the packages.

A Common Vulnerabilities and Exposures (CVE) lands in a package deep in your stack: a model framework, a transitive dependency, something pinned years ago. The official fix is often a new major version that would break your application. That leaves you stuck between shipping insecure software and rewriting working systems under pressure. This is what remediation solves.

02

Compromise of the build chain.

A package on a public index is not the source you reviewed. It is a wheel or RPM built from that source through a chain of tools and credentials. Attackers have compromised that chain and swapped real code for malicious code mid-build, so the artifact no longer matches what you can read. This is what building from source solves.

One team, three workstreams.

The same upstream maintainers who steward these packages run three coordinated workstreams against your dependency inventory — a security engineer leads every one.

Three workstreams

01 Remediation

Fix the vulnerabilities in the packages you can’t safely upgrade away.

02 Build from source

Secure the path your packages take from source to production.

03 Secure registry

A trusted, self-hostable home to keep what you install.

The Python + AI supply chain

LAYER 06 · PLATFORM

Platform

Where teams actually work — Intelligence Hub + Nebari

OPENTEAMS STANDING
OpenTeams builds and maintains the platform layer itself.

AT THIS LAYER

Built & maintained by OpenTeams

LAYER 05 · INTERACTIVE

Interactive / Notebooks

JupyterHub and the Jupyter ecosystem

OPENTEAMS STANDING

Jupyter Foundation Governing Board representation plus technical subproject leadership.

AT THIS LAYER

Built & maintained by OpenTeams

LAYER 04 · CORE LIBRARIES

Core libraries

Foundational AI/data libraries — NumPy, SciPy, scikit-learn, Matplotlib, Dask, Numba (plus PyTorch, Pandas)

OPENTEAMS STANDING

Maintainers — and in several cases steering-council members — across these projects.

AT THIS LAYER

Maintainers & steering-council members

LAYER 03 · PACKAGE MANAGERS

Package managers

How software gets installed — pip, conda

OPENTEAMS STANDING

Maintainers of core packaging tools — manylinux, meson-python, pypa/build, cibuildwheel, pyproject-metadata, pkgconf-pypi, pypackaging-native; WheelNext / Wheel Variants contributors.

AT THIS LAYER

Core packaging-tool maintainers

LAYER 02 · PACKAGE INDEXES

Package indexes

Where packages live — PyPI, conda-forge

OPENTEAMS STANDING

conda Steering Council members; conda-forge core team — the governing body of conda-forge.

AT THIS LAYER

conda Steering Council + conda-forge core

LAYER 01 · FOUNDATION

Standards & foundation

The rules of the ecosystem — Python packaging standards, PEPs, PyPA

OPENTEAMS STANDING

Python Packaging Authority (PyPA) contributors & maintainers; PEP authors; Jupyter Foundation governance.

AT THIS LAYER

PyPA contributors & PEP authors

Our seat at the table

Conda

1

Steering Council seat

+4 emeritus

conda-forge

4

Core team members

+3 emeritus

NumPy

5

Steering Council seats

+1 emeritus

SciPy

1

Steering Council seats

+2 emeritus

Jupyter

1

Governing Board seat

PSF

1

Board of Directors seat

scikit-learn

Active contributors

PyPA

Core contributors & PEP authors

Numbers reflect combined OpenTeams + Quansight standing.

NASA-funded work to secure scientific Python.

Our engineers have led NASA-funded work on supply-chain security, reproducible builds, and performance across foundational scientific Python projects.
Grants

Two active NASA grants

Reference
NASA #80NSSC22K0405, “Reinforcing the Foundations of Scientific Python” (first grant, 2022 to 2025) · NASA ROSES #80NSSC25K7215, “Ensuring a Fast and Secure Core for Scientific Python…” (second grant)
Period

Jan 2025 – Jan 2028 (second grant)

“Ensuring a Fast and Secure Core for Scientific Python: Security, Accessibility and Performance of NumPy, SciPy and scikit-learn; Going Beyond NumPy With Accelerator Support”

What the grant work covers
01

Supply chain and reproducible builds:

Designing and implementing reproducible-build strategies for foundational data-science libraries, so a binary can be independently verified against its source.

02

Build-pipeline hardening:

Securing the source-to-package build process for core scientific tooling, the same build-chain integrity work we bring to enterprise engagements.

03

Accelerator support:

Extending the scientific core with hardware-accelerator support, so the libraries stay fast as well as secure.

Workstream

01

Workstream

01

We don’t report vulnerabilites.
We remediate them.

Most vendors wait for the open-source community to publish a fix, then pass it along. We work inside the upstream communities that maintain the packages your AI stack depends on, fixing vulnerabilities at the source. While the permanent patch moves through the release process, we deliver a validated fix through a private channel you control, protecting you now without leaving you with a private fork to maintain.

How it works

01

Identify & triage

02

Fix at the source

03

Validate

04

Deliver immediately

05

Land it upstream

Workstream

02

Workstream

02

Trust that your binaries match
the source you reviewed.

Installing from a public index takes trust. You trust that the wheel or RPM you downloaded was actually built from the source you can inspect. That is the build-integrity problem: the security gap between source code and the artifact your systems actually install.

 

Most real supply-chain compromise happens in that gap: the build and distribution chain, not the source repo.

Security-sensitive engineering organizations close the gap by building from source inside their own environment instead of depending on what a public index hands them.

Two ways to get there, you choose where it lives

Option

What it is

Best for

Hosted secure channel

We build your critical dependencies from source and deliver them through a private channel you pull from.

Teams that want the outcome without running the infrastructure.

Inside your own environment

We stand up the same secure build pipeline entirely within your org, your packages, your servers, your control.

Security-sensitive enterprises that keep dependencies fully in-house.

Workstream

03

Workstream

03

An open-source, self-hostable home for the packages your teams trust.

Securing what you install is only half the problem, you also need somewhere trusted to keep it. Most teams already run a commercial artifact registry, we integrate with those. For teams that don’t, or that want an open alternative, we bring our own: an open-source, self-hostable artifact registry, Artifact Keeper.

Already on a commercial registry?

Move at your own pace

Built-in migration brings over your repositories, artifacts, and permissions. It reads from your existing registry without modifying it, so you migrate incrementally, not in one risky cutover.

Artifact Keeper is being folded into the broader Nebari platform, so the pieces — secure registry, scanning, and remediation — fit together as one story rather than a bag of tools. It manages, scans, quarantines, and serves artifacts. It does not rebuild or generate packages, and it doesn’t decide what your teams can install.

If your business runs on AI, let’s make sure you can trust the stack it’s built on.

Tell us what you’re running and our engineers will tell you what we can do about it: the vulnerabilities we can remediate, and the build chain we can secure.

Matched to your actual dependency inventory

A security engineer leads every conversation

Layers onto the OS and container security you already run

We use cookies

We use cookies to improve your experience on this website. You may choose which types of cookies to allow and change your preferences at any time. Disabling cookies may impact your experience on this website. You can learn more by viewing our Cookie Policy.