Model bezpieczeństwa

Najważniejsze mechanizmy egzekwowane poza agentem.

Kod projektu działa w kontenerze Linux z ograniczonymi uprawnieniami.

Worker ma ograniczony zestaw Linux capabilities i ustawienie no-new-privileges, które blokuje uzyskanie dodatkowych uprawnień przez setuid lub uprawnienia plików wykonywalnych. Zarządzane narzędzia runtime są montowane tylko do odczytu. Root wewnątrz workera nie daje kontroli nad hostem ani osobną przestrzenią sieciową proxy.

Osobny daemon Docker rootless działa poza kontenerem workera na jednorazowym węźle; nie jest współdzielony między zadaniami klientów. Worker otrzymuje socket filtra API, który sprawdza operacje, opcje kontenerów i źródła montowań oraz blokuje kontenery uprzywilejowane.

Warm node to nieużyta maszyna; po operacji jest usuwana, nigdy przydzielana ponownie.

Po operacji platforma unieważnia autoryzację runtime, usuwa kontenery, zatrzymuje osobny daemon Dockera i zleca usunięcie węzła. Pozostałe volumes, build cache, workspace, /tmp i lokalne dane baz kończą swój cykl życia wraz z usunięciem maszyny. Błąd cleanupu nie przywraca jej do puli.

Ponowne użycie dotyczy wersjonowanych obrazów AWE i cache danego projektu. Izolacja opiera się na jednorazowych węzłach, nie na czyszczeniu i przekazywaniu użytej maszyny innemu zadaniu lub klientowi.

Proxy dodaje zarządzane uwierzytelnianie do dozwolonych żądań.

Zarządzane tokeny modeli i publikacji pozostają poza przestrzenią roboczą agenta. Dla obsługiwanych operacji proxy pobiera uwierzytelnianie z usługi poświadczeń i dodaje wymagane nagłówki do żądań kierowanych do skonfigurowanych hostów. Może też odświeżać uwierzytelnianie bez udostępniania agentowi tokena.

Przed dodaniem tokena proxy wymaga zgodności hosta HTTP z nazwami TLS klienta i serwera docelowego oraz HTTPS na porcie 443. Sprawdza też URL, nagłówki i surową treść żądania pod kątem znanych poświadczeń, w tym ich reprezentacji URL-encoded i Base64. Próba wysłania ich do niedozwolonego adresata kończy się odpowiedzią 403. Każde żądanie po przekierowaniu podlega ponownej kontroli. Ochrona dotyczy znanych poświadczeń proxy, nie dowolnych danych projektu.

Publikacja korzysta z osobnych poświadczeń platformy; worker nie dostaje bezpośrednich uprawnień do publikowania. Ta separacja dotyczy zarządzanych poświadczeń, a nie sekretów zapisanych już w kodzie, treści issue lub wynikach komend.

Ruch HTTP(S) workera i zagnieżdżonych kontenerów przechodzi przez proxy.

Granica sieciowa jest egzekwowana poza workerem, niezależnie od UID procesu. Ruch HTTP(S) jest przechwytywany przez proxy, DNS ograniczony do wskazanych resolverów, pozostałe przekazywanie ruchu blokowane, a IPv6 wyłączone. Zagnieżdżone kontenery Dockera korzystają z tej samej granicy ruchu wychodzącego.

Proxy sprawdza metodę HTTP i cel żądania. Metody zapisu są ograniczone do jawnej listy dozwolonych hostów; żądania odczytu mają szerszy dostęp potrzebny do pobierania zależności i kontekstu. Dane nadal mogą trafić do adresu URL lub dozwolonej usługi, więc filtrowanie nie gwarantuje ochrony przed każdym wyciekiem.

Token GitHub workera jest ograniczony do repozytorium danego zadania.

Token instalacji GitHub App używany przez workera jest ograniczony do repozytorium danego zadania. Nie daje dostępu do innych prywatnych repozytoriów, nawet jeśli należą do tej samej instalacji aplikacji. Publiczne repozytoria pozostają dostępne przez dozwolone żądania sieciowe.

Usługa publikacji zapisuje zmiany wyłącznie w repozytorium danego zadania. Prywatne zależności i submoduły w innych repozytoriach wymagają osobnej autoryzacji; token workera jej nie zapewnia.

Osobna usługa publikuje poprawkę i odrzuca zmiany chronionych ścieżek CI.

Przed zapisem wyniku usługa publikacji sprawdza zmienione ścieżki. Poprawka obejmująca .github/workflows/, .github/actions/, wykryte katalogi lokalnych akcji lub pliki action.yml / action.yaml jest odrzucana w całości. Agent ma też instrukcję odmowy zadań wymagających zmian konfiguracji CI.

Analiza bezpieczeństwa CI zgłasza ustalenia, ale nie blokuje zadań. Ochrona plików workflow nie blokuje wykonania zmienionego kodu aplikacji przez istniejące buildy, testy lub skrypty instalacyjne. Platforma otwiera pull request do przeglądu, a decyzję o merge’u pozostawia Tobie.

OpenAI jest obecnie jedynym dostawcą modeli używanym przez Codebase.run.

Codebase.run korzysta obecnie wyłącznie z OpenAI jako dostawcy modeli. Treść issue, wybrane fragmenty kodu i wyniki narzędzi trafiają do OpenAI jako kontekst pracy agenta. Poświadczenie OpenAI jest dodawane przez proxy, zamiast być udostępniane w przestrzeni roboczej agenta.

Pull requesty i komunikaty postępu są publikowane w docelowym repozytorium. Izolacja kontenera nie zatrzymuje kontekstu modelu lokalnie. Retencja i wykorzystanie danych do trenowania zależą od warunków właściwej usługi OpenAI i jej konfiguracji; ten model bezpieczeństwa nie ustanawia osobnej polityki w tych obszarach.

Zabezpieczenia ograniczają uprawnienia agenta, ale poniższe ryzyka pozostają.

Wyciek danych: kod lub wyniki narzędzi mogą trafić do adresów URL żądań albo do dozwolonych usług. Filtrowanie sieci nie sprawdza poufności każdej przesyłanej informacji.

Złośliwe instrukcje: issue, plik repozytorium, zależność lub zewnętrzna strona mogą skierować agenta do niezamierzonych działań w ramach dostępnych uprawnień, w tym szkodliwych zmian kodu. Oddzielenie poświadczeń nie gwarantuje zachowania zgodnego z zadaniem.

Sekrety w projekcie: poświadczenia zapisane już w kodzie, danych testowych lub wynikach komend mogą zostać odczytane przez agenta i trafić do kontekstu modelu albo wygenerowanego wyniku. Obsługa poświadczeń w proxy nie usuwa sekretów z treści projektu.

Wykonanie w CI: istniejące testy, buildy i skrypty instalacyjne mogą uruchomić zmieniony kod z uprawnieniami zadania CI, w tym dostępem do sekretów lub usług zewnętrznych. Może to nastąpić po otwarciu PR-a, przed review i merge’em, nawet bez zmian plików workflow.

Błędne lub niebezpieczne zmiany: przechodzące testy mogą nie wykryć regresji, podatności i złośliwego zachowania. Przed merge’em sprawdź diff i dowody weryfikacji, szczególnie przy zmianach zależności i skryptów wykonywalnych.