Inwentarz komponentów

Z czego składa się wdrożenie AgenticOS: części pisane w tym projekcie, zewnętrzne pakiety, od których zależą, obrazy, w których działają, zasoby, które dostarczają, oraz modele i usługi podłączane przez operatora później. To czytelna połowa SBOM-u wydania i odpowiedź na pytanie „co jest w środku”, gdy pada ono podczas przeglądu bezpieczeństwa, a nie w systemie budowania.

Co ta strona obejmuje i gdzie się kończy

Wszystko do sekcji Dostarczane zasoby włącznie jest dostarczane przez ten projekt i wyliczone dokładnie — z plików lock i z Dockerfile'i. Wszystko po niej — modele, providerzy, serwery MCP, bazy danych, na które wskazuje wdrożenie — jest wybierane per wdrożenie, nie jest tu dostarczane i może zostać wypisane wyłącznie przez to wdrożenie, które je wybrało. Ostatnia sekcja mówi, jak spisać tę drugą połowę; ta strona nie zrobi tego za Ciebie.

Inwentarz odczytywalny maszynowo jest dołączany do każdego wydania jako sześć dokumenty CycloneDX — po jednym na obraz na architekturę, bo opublikowany tag jest listą manifestów, a oba warianty nie zawierają tych samych pakietów. Dowody licencyjne dla każdego komponentu znajdziesz w THIRD_PARTY_NOTICES.md, a przegląd tego, do czego te licencje zobowiązują — w Licencjach i notach o oprogramowaniu firm trzecich.

Wydanie, które opisuje ten inwentarz

Inwentarz bez numeru wersji nie opisuje niczego. Każde wydanie ma własny: dokumenty SBOM na wydaniu GitHub dla tagu vX.Y.Z, wygenerowane z obrazów opublikowanych pod tym tagiem, oraz tę stronę w postaci, w jakiej była w drzewie tego tagu. Wdrożenie czytające inwentarz dla wersji, którą uruchamia, powinno czytać oba z tego samego tagu, a nie z main.

Artefakt	Gdzie jest	Co nazywa jego wersję
sbom-api-amd64.cdx.json, sbom-api-arm64.cdx.json	zasoby wydania GitHub	tag v*, do którego są dołączone
sbom-frontend-amd64.cdx.json, sbom-frontend-arm64.cdx.json	tam samo	tak samo
sbom-browser-amd64.cdx.json, sbom-browser-arm64.cdx.json	tam samo	tak samo
ghcr.io/vstorm-co/agenticos-backend	GHCR	<version>, latest, edge, sha-<short>
ghcr.io/vstorm-co/agenticos-frontend	GHCR	tak samo
ghcr.io/vstorm-co/agenticos-browser	GHCR	tak samo
THIRD_PARTY_NOTICES.md	repozytorium, na tym tagu	pliki lock w tym commicie

Komponenty pisane w tym projekcie

Własne, na licencji Apache-2.0, w tym repozytorium. Nic tutaj nie jest komponentem firmy trzeciej i nic z tego nie pojawia się w notach.

Komponent	Gdzie	Czym jest	Dostarczany w
API i platforma	backend/app	Aplikacja FastAPI: routes, services, repositories, runner agentów, rejestr capability	agenticos-backend
Worker w tle	backend/app/worker	Pobiera zadania z kolejki w PostgreSQL - runy agentów, ingestię, synchronizacje, sweepy - i odpala harmonogramy wdrożenia (python -m app.worker)	agenticos-backend
Migracje	backend/alembic	Łańcuch schematu, stosowany przez usługę migracji przed startem API	agenticos-backend
Wiersz poleceń	backend/app/commands	agenticos cmd … — bootstrap, doctor, polecenia RAG	agenticos-backend
Konsola	frontend/src	Aplikacja Next.js, którą widzi operator i użytkownik	agenticos-frontend
Powłoka desktopowa	desktop/	Okno Tauri wokół konsoli wdrożenia, budowane per platforma	nie jest obrazem; zobacz aplikację desktopową
Strona dokumentacji	docs/, mkdocs.yml	Ta strona	nie jest dostarczana w żadnym z obrazów

Zależności firm trzecich

Rozwiązywane z plików lock, a nie z tego, co akurat ma zainstalowana maszyna. Liczby zmieniają się z każdą zmianą zależności, więc wartością, której warto ufać, jest ta w pliku not dla wydania, które czytasz.

Zbiór	Plik lock	Rozwiązywany dla	W notach
Dystrybucje Pythona backendu	backend/uv.lock	Linux, obie architektury, --no-dev	Tak
Pakiety npm frontendu	frontend/bun.lock	produkcyjne domknięcie frontend/package.json	Tak
Narzędzia deweloperskie i dokumentacyjne backendu	backend/uv.lock, grupy dev i docs	maszyna kontrybutora	Nie: nie ma ich w żadnym obrazie
devDependencies frontendu	frontend/bun.lock	maszyna kontrybutora	Nie: nie ma ich w obrazie
Crate'y Rusta powłoki desktopowej	desktop/src-tauri/Cargo.lock	platforma, dla której budowana jest powłoka	Nie: nie ma ich w żadnym obrazie

Dwa audyty czytają te pliki lock przy każdym pull requeście. make audit rozwiązuje backend/uv.lock i sprawdza go wobec bazy podatności; make audit-frontend uruchamia bun audit --audit-level=high na frontend/bun.lock. Oba są w zadaniu Security Scan i w make check.

Obrazy uruchomieniowe

Obraz	Baza	Zawiera	Budowany przez
agenticos-backend	obraz Pythona oparty na Debianie	API, worker, migracje, CLI, domknięcie zależności backendu, teksty licencji	backend/Dockerfile
agenticos-frontend	obraz Node'a oparty na Debianie	standalone build konsoli, jej produkcyjne domknięcie zależności, fonty, noty per pakiet	frontend/Dockerfile
agenticos-browser	debian:bookworm-slim	Chromium z oknem pod Xvfb, fonty z pulpitu i socat do jego DevTools - to, co uruchamia profil browser w compose dla capability przeglądarki	docker/browser/Dockerfile

Wszystkie trzy są budowane dla amd64 i arm64, publikowane do GHCR i skanowane Trivy po publikacji. Pakiety Debiana instalowane przez każdy obraz są zapisane w licenses/components.toml wraz z ich pozycją licencyjną i pojawiają się w dokumentach CycloneDX, bo generator czyta opublikowany obraz, a nie drzewo źródeł.

Usługi, które wdrożenie uruchamia obok tych trzech — PostgreSQL z pgvector, Redis, reverse proxy, proxy wyjściowe przeglądarki (Squid) — operator pobiera od ich własnych wydawców. Są nazwane w plikach compose, nie są tu budowane i nie ma ich w SBOM-ie tego projektu.

Dostarczane zasoby

Zasób	Gdzie	Pochodzenie
Fonty interfejsu	frontend/src/app/fonts/	Inter, Bricolage Grotesque, Geist Mono, wszystkie OFL-1.1
Glify marek i providerów	frontend/src/components/brand/, backend/app/core/catalog/icons/	Font Awesome, Simple Icons i znaki rysowane ręcznie; źródła nazywa NOTICE
Katalog serwerów MCP	backend/app/core/catalog/	Własne dane tego projektu o serwerach firm trzecich, nie same serwery
Domyślne profile modeli	backend/app/core/catalog/	Własne dane tego projektu; same modele nigdy nie są dostarczane

Modele, providerzy i usługi: połowa należąca do wdrożenia

Nic z poniższych nie jest częścią wydania i żaden SBOM wygenerowany tutaj nie może tego wypisać. Każda pozycja jest komponentem działającego systemu i należy do własnego inwentarza wdrożenia.

• Providerzy modeli. Ci z Anthropic, OpenAI, Google, Groq, xAI, Cohere, endpointu zgodnego z OpenAI lub lokalnego runtime'u, których wdrożenie skonfiguruje, wraz z przypiętymi identyfikatorami modeli. Zobacz modele.
• Wagi modeli. Lokalny runtime je pobiera; ich licencje przegląda operator, a przegląd licencji mówi dlaczego.
• Serwery MCP. Procesy firm trzecich lub hostowane endpointy, podłączane per organizacja. Katalog nazywa kandydatów; instalacja jest komponentem.
• Źródła wiedzy i konektory. Google Drive, S3 i pozostałe, każde jako usługa firmy trzeciej osiągana poświadczeniem z vault.
• Kanały. Przestrzenie Slacka, Telegrama i Mattermosta, w których wdrożenie jest zarejestrowane.
• Magazyny danych i infrastruktura. PostgreSQL, Redis, storage obiektowy, reverse proxy, host oraz dowolny endpoint obserwowalności odbierający trace'y.

SBOM obrazu to nie inwentarz systemu

Dokumenty CycloneDX opisują trzy obrazy. Wdrożenie, które podłącza hostowany model, trzy serwery MCP i storage obiektowy, uruchamia komponenty, których żaden skan tych obrazów nie zobaczy. Traktowanie SBOM-u wydania jako całego inwentarza jest luką, którą ta sekcja ma nazwać.

Jak inwentarz powstaje i jest utrzymywany

Artefakt	Wytwarzany przez	Kiedy
Sześć SBOM-ów wydania	zadanie sbom w .github/workflows/images.yml, po jednym na obraz na architekturę, z opublikowanych manifestów	przy każdej publikacji; dołączane do wydania na tagu v*, w pozostałych przypadkach jako artefakt przebiegu
THIRD_PARTY_NOTICES.md	make licenses	gdy zmienia się plik lock; make licenses-check przerywa budowanie, gdy plik jest nieaktualny
Ta strona	ręcznie	gdy komponent zostaje dodany, usunięty lub przeniesiony między powyższymi zbiorami

make sbom zapisuje coś innego i nazwy to mówią: sbom-source-api.cdx.json i sbom-source-frontend.cdx.json są inwentarzami tego, co deklaruje drzewo źródeł, a nie tego, co zawiera obraz. Niosą grupy zależności deweloperskich i dokumentacyjnych, jeśli są zainstalowane, i żadnej z warstw pod spodem — bez obrazu bazowego, bez pakietów Debiana, bez zbudowanych artefaktów. Przydatne do przeczytania zbioru zależności bez pobierania dwóch obrazów; bezużyteczne jako dowód tego, co dostarcza wydanie, do czego służy sześć dokumentów powyżej. Wymaga zainstalowanego syfta i świadomie nie należy do make check.

Aby rozszerzyć inwentarz dla wdrożenia, weź SBOM wydania dla uruchamianej wersji, dodaj komponenty z powyższej sekcji wraz z wersją i dostawcą każdego z nich i trzymaj to obok własnej konfiguracji wdrożenia. Przegląd bezpieczeństwa jest miejscem, w którym recenzent klienta o to poprosi, a ochrona danych miejscem, w którym spisane są dane dotykane przez każdy z tych komponentów.