Source dependencies
Include supported package manifests and exact lockfiles. Review recognized components, unresolved versions and the advisory information used before interpreting a zero-finding result.
Review SAST and dependency scope →Free 30-min security demo — Explore the products, deployment and workflows that fit your team Book Now
Software supply chain security
A package advisory, a source-code weakness and an unsafe deployment setting need different evidence. Use Offensive360 to investigate supported dependency inputs and source code, and evaluate image archives, SBOMs and Kubernetes manifests in the cloud demo.
Use a representative application and release artifact. Record where the inventory came from, which checks completed and what still needs investigation.
Include supported package manifests and exact lockfiles. Review recognized components, unresolved versions and the advisory information used before interpreting a zero-finding result.
Review SAST and dependency scope →Review source findings with concrete code context and remediation guidance. Framework behavior, authorization boundaries and runtime configuration may need additional investigation.
Explore source-code analysis →Evaluate a Docker/OCI image archive or CycloneDX/SPDX JSON SBOM in the cloud demo. Compare the analyzed inventory with the release you intend to deploy.
Explore container and SBOM scanning →Assess uploaded Kubernetes resource manifests for supported configuration checks. Live-cluster state, referenced image contents and runtime behavior are separate assessment questions.
Review manifest analysis scope →For license obligations, malware investigation, provenance requirements or live runtime monitoring, specify the acceptance criteria separately and confirm the available capability. A vulnerability advisory scan does not establish these outcomes.
Software supply chain security examines the components and processes used to build and deliver software. Dependency assessment, source review, artifact analysis and deployment-configuration review answer different questions and should be evaluated with explicit scope.
Source dependency analysis uses supported manifests and lockfiles to identify components. Container image scanning examines supported package information in the supplied image archive. The inventories can differ because a build adds, removes or changes components. Assess the artifact you intend to ship as well as the source project.
An SBOM describes components recorded by its producer. Matching recognized names and exact versions to advisory data can identify potential exposure. It does not prove that the inventory is complete, that all components are deployed, or that an advisory is exploitable in your application.
No. Check that the expected dependencies were recognized, that analysis completed and that the advisory snapshot was suitable. Source-code weaknesses, unknown vulnerabilities and application-specific authorization or runtime issues require separate investigation.
Discuss the product release, supported analyzers, advisory updates and network requirements for your intended deployment. Cloud artifact scanning and an offline appliance are different evaluation scopes. Agree data handling and external AI settings before providing source code or artifacts.
The Offensive360 Team · Updated October 3, 2026. Product availability, scan capacity, deployment and support should be recorded in your commercial scope.