Skip to main content
POST
Code-Scan starten

Berechtigungen

Erfordert einen Service-Benutzer oder ein persönliches Zugriffstoken mit der Berechtigung UseCodeScans auf Organisationsebene.

Verhalten

Stellt einen neuen Code-Scan für das angegebene Repository (repo_name) oder die angegebenen Repositorys (repos) in der Organisation in die Warteschlange. Der Scan wird vom Scan-Dispatcher asynchron gestartet; die Antwort enthält den Scan-Datensatz mit dem anfänglichen status waiting oder pending. Rufen Sie Code-Scans auflisten auf, um den Fortschritt zu verfolgen, und Code-Scan-Befunde auflisten (gefiltert nach scan_id), um die Ergebnisse abzurufen, sobald der Scan den Status completed erreicht. Der Scan wird dem aufrufenden Principal zugeordnet (dem Service-Benutzer oder PAT, der die Anfrage gestellt hat). Das Äquivalent mit Enterprise-Geltungsbereich ist Code-Scan starten (Enterprise).

Anfragefelder

Geben Sie genau eines der Felder repo_name oder repos an.
  • repo_name: vollständiger Repository-Name, z. B. owner/repo. Das Repository muss bereits über die Git-Integration der Organisation zugänglich sein.
  • host: Git-Host des Repositorys, falls er nicht abgeleitet werden kann.
  • repos: Repositorys, die ein einzelner Multi-Repo-Scan abdeckt, als Liste von Objekten mit repo_name und optionalem host (maximal 200). Der erste Eintrag ist das primäre Repository des Scans.
  • profile_id: anzuwendendes Scan-Profil. Verwenden Sie Ingestion-Scan starten für Profile im ingest-Modus.
  • scan_type: Typ des auszuführenden Scans. Wenn profile_id angegeben ist, muss er dem Scan-Typ des Profils entsprechen. Standardmäßig wird der Typ des Profils verwendet, bei Scans ohne Profil security. Nicht sicherheitsbezogene Scan-Typen erfordern ein Profil.
  • commit_sha: Commit, der vor dem Scannen ausgecheckt werden soll. Standardmäßig wird der aktuelle Stand des Standard-Branches des Repositorys verwendet.
  • effort: normal (Standard) arbeitet mit geringerem Reasoning-Aufwand des Modells und größeren Untersuchungs-Batches; deep durchläuft die vollständige Pipeline.
  • interactive: Bei true hält der Scan zwischen Threat Modeling und Untersuchung im Status awaiting_user_input an, damit Nutzer ein Review durchführen können. Standardmäßig false. Interaktives Review wird nur von Sicherheits-Scans unterstützt; andere Scan-Typen laufen ohne Eingriff durch.
  • platform: wo die Sitzungen des Scans ausgeführt werden – entweder ein für die Organisation konfiguriertes Plattform-Label (zum Beispiel linux, windows oder macos) oder der Name eines Outpost-Pools; Groß-/Kleinschreibung wird nicht berücksichtigt. Passt ein Name auf beides, hat die Plattform Vorrang. Standardmäßig gilt die Standardeinstellung der Organisation.

Fehler

  • 400, wenn scan_type mit dem Profil in Konflikt steht, ein nicht sicherheitsbezogener scan_type ohne Profil angegeben wird oder platform keinem konfigurierten Plattform-Label und keinem Outpost-Pool entspricht (der Fehlertext listet die verfügbaren Werte auf).
  • 403, wenn die Organisation auf reine Ingestion-Scans beschränkt ist und kein Profil im ingest-Modus angegeben wird.
  • 404, wenn das Repository oder Profil für die Organisation nicht sichtbar ist.
  • 409, wenn der Scan-Backlog der Organisation ausgelastet ist. Versuchen Sie es später erneut.
  • 422, wenn entweder sowohl repo_name als auch repos oder keiner der beiden Parameter angegeben wird oder wenn repos leer ist.

Autorisierungen

Authorization
string
header
erforderlich

Servicebenutzer-Anmeldedaten (Präfix: cog_)

Pfadparameter

org_id
string
erforderlich

Organisations-ID (Präfix: org-)

Beispiel:

"org-abc123def456"

Body

application/json

Anfragebody zum Starten eines neuen Code-Scans.

commit_sha
string | null

Commit, der vor dem Scan ausgecheckt werden soll.

effort
enum<string> | null

Scan-Aufwand: 'normal' (Standard) verwendet einen geringeren Reasoning-Aufwand des Modells und größere Untersuchungspakete; 'deep' führt die vollständige Pipeline aus.

Verfügbare Optionen:
normal,
deep
host
string | null

Git-Host des Repositorys, sofern bekannt.

interactive
boolean
Standard:false

Bei true pausiert der Scan zwischen Bedrohungsmodellierung und Untersuchung, damit der Nutzer die Ergebnisse überprüfen kann.

new_budget
NewScanBudget · object | null

Weisen Sie dem Scan ein eigenes ACU-Budget zu. Erfordert die Berechtigungen ManageAccountServiceUsers und ManageAcuLimits.

platform
string | null

Ausführungsort der Scan-Sitzungen: eine für die Organisation konfigurierte Plattformbezeichnung (z. B. 'linux', 'windows', 'macos') oder der Name eines Outpost-Pools (BYOB). Groß- und Kleinschreibung werden nicht berücksichtigt; bei gleichnamigen Plattformen und Pools haben Plattformen Vorrang. Ohne Angabe gilt der Organisationsstandard. Unbekannte Werte werden mit dem HTTP-Statuscode 400 abgelehnt; die Fehlerantwort listet die verfügbaren Plattformbezeichnungen und Outpost-Pool-Namen auf.

Maximum string length: 128
profile_id
string | null

Scan-Profil, das auf den Scan angewendet werden soll.

repo_name
string | null

Vollständiger Name des zu scannenden Repositorys. Geben Sie entweder repo_name oder repos an, nicht beides.

repos
ScanRepoRequest · object[] | null

Repositorys, die ein Scan abdeckt; der erste Eintrag ist das primäre Repository des Scans. Geben Sie entweder repo_name oder repos an, nicht beides.

Maximum array length: 200
scan_type
enum<string> | null

Typ des auszuführenden Scans. Muss bei Angabe eines Profils dessen Scan-Typ entsprechen. Standardmäßig wird der Typ des Profils verwendet, bei Scans ohne Profil 'security'. Andere Typen als 'security' erfordern ein Profil und werden ohne Profil abgelehnt.

Verfügbare Optionen:
security,
performance,
db-queries,
test-coverage,
dead-code,
code-quality,
cleanup,
telemetry,
accessibility,
compliance,
general,
migration-docs

Antwort

Erfolgreiche Antwort

Ein einzelner Code-Scan.

created_at
integer
erforderlich

Zeitpunkt, zu dem der Scan erstellt wurde (Unix-Sekunden).

effort
enum<string>
erforderlich

Scan-Aufwand: 'normal' nutzt einen geringeren Reasoning-Aufwand des Modells und größere Untersuchungspakete; 'deep' führt die vollständige Pipeline aus.

Verfügbare Optionen:
normal,
deep
host
string | null
erforderlich

Git-Host des Repositorys, falls bekannt.

org_id
string
erforderlich

Organisation, zu der der Scan gehört.

profile
CodeScanProfileResponse · object | null
erforderlich

Profil, unter dem der Scan ausgeführt wurde, falls vorhanden.

repo_name
string
erforderlich

Primäres Repository des Scans. Multi-Repo-Scans umfassen zusätzliche Repositorys, die hier nicht aufgeführt sind.

scan_id
string
erforderlich

Eindeutige Kennung des Scans.

scan_type
enum<string>
erforderlich

Typ des Scans, bei der Erstellung festgelegt.

Verfügbare Optionen:
security,
performance,
db-queries,
test-coverage,
dead-code,
code-quality,
cleanup,
telemetry,
accessibility,
compliance,
general,
migration-docs
status
enum<string>
erforderlich

Scan-Status: waiting, pending, running, awaiting_user_input, completed, failed oder cancelled.

Verfügbare Optionen:
waiting,
pending,
running,
awaiting_user_input,
completed,
failed,
cancelled
url
string
erforderlich

URL der Scan-Seite in der Devin-Webapp.

outpost_pool_id
string | null

Outpost-Pool, auf dem die Sitzungen des Scans ausgeführt werden, sofern festgelegt.

platform
string | null

Bezeichnung der gehosteten Plattform, auf der die Sitzungen des Scans ausgeführt werden. Null, wenn der Scan auf einem Outpost-Pool oder mit der Standardeinstellung der Organisation ausgeführt wird.

repo_full_name
string | null

Kennung des primären Repositorys einschließlich Host (z. B. github.com/org/repo). Null für Perforce-Depots, die keinen Git-Host haben.