Skip to main content
POST
Code-Scan starten

Berechtigungen

Erfordert einen Service-Benutzer oder ein Personal Access Token mit der Berechtigung UseAccountCodeScans auf Unternehmensebene.

Verhalten

Stellt einen neuen Code-Scan für das angegebene Repository (repo_name) bzw. die angegebenen Repositorys (repos) in der angegebenen 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 regelmäßig Code-Scans auflisten auf, um den Fortschritt zu verfolgen, und verwenden Sie 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).

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 automatisch ermittelt werden kann.
  • repos: Repositorys, die von einem einzelnen Multi-Repo-Scan abgedeckt werden, als Liste von Objekten mit repo_name und optionalem host (bis zu 200). Der erste Eintrag ist das primäre Repository des Scans.
  • profile_id: ein anzuwendendes Scan-Profil. Verwenden Sie Ingestion-Scan starten für Profile im Modus ingest.
  • scan_type: Typ des auszuführenden Scans. Bei Angabe von profile_id 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 Scan ausgecheckt werden soll. Standardmäßig wird der HEAD des Standard-Branches des Repositorys verwendet.
  • effort: normal (Standard) nutzt einen geringeren Reasoning-Aufwand des Modells bei größeren Untersuchungs-Batches; deep führt die vollständige Pipeline aus.
  • interactive: Bei true hält der Scan zwischen Threat Modeling und Untersuchung im Status awaiting_user_input an, damit der Nutzer ein Review durchführen kann. Standardmäßig false. Interaktive Reviews werden nur von Sicherheits-Scans unterstützt; andere Scan-Typen laufen ohne Eingriff durch.
  • platform: Ort, an dem 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, ohne Beachtung der Groß-/Kleinschreibung. Passt ein Name auf beides, haben Plattformen Vorrang. Standardmäßig wird der Standardwert der Organisation verwendet.

Fehler

  • 400, wenn scan_type nicht mit dem Profil übereinstimmt, 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 die Organisation, das Repository oder das Profil für das Enterprise-Konto nicht sichtbar ist.
  • 409, wenn das Scan-Backlog der Organisation seine Kapazitätsgrenze erreicht hat. Versuchen Sie es später erneut.
  • 422, wenn entweder sowohl repo_name als auch repos oder keines von beiden 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

Request-Body 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, falls bekannt.

interactive
boolean
Standard:false

Bei true wird der Scan zwischen Bedrohungsmodellierung und Untersuchung für ein Review durch den Nutzer angehalten.

platform
string | null

Wo die Sitzungen des Scans ausgeführt werden: eine für die Organisation konfigurierte Plattformbezeichnung (z. B. 'linux', 'windows', 'macos') oder der Name eines Outpost-Pools (BYOB), unabhängig von der Groß-/Kleinschreibung. Wenn ein Name sowohl einer Plattform als auch einem Pool entspricht, hat die Plattform Vorrang. Wird der Wert weggelassen, gilt der Standard der Organisation. 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, aber nicht beide.

repos
ScanRepoRequest · object[] | null

Repositorys, die von einem Scan erfasst werden; der erste Eintrag ist das primäre Repository des Scans. Geben Sie entweder repo_name oder repos an, aber nicht beide.

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

Art des auszuführenden Scans. Muss dem Scan-Typ des Profils entsprechen, wenn ein Profil angegeben ist; standardmäßig wird der Typ des Profils verwendet, oder 'security' für Scans ohne Profil. Nicht sicherheitsbezogene Typen erfordern ein Profil und werden ohne eines 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.