SectionApplication Security
Technology category
SAST
SAST belongs to the Application Security area. SAST analyzes source code or binaries without running the application. It helps detect development flaws before deployment.
Acronym Glossary
This glossary explains acronyms used in this part so the intended security function is clear.
- SAST
- Static Application Security TestingStatic testing of source code or binaries without running the application.
What This Technology Covers
SAST analyzes source code or binaries without running the application. It helps detect development flaws before deployment.
Why It Matters
It is suitable for development teams that want to shift security into the pipeline and reduce remediation cost.
In practice, this is not only a technical function. It is a way to place the solution into a broader security architecture. Many organizations operate dozens of consoles and tools, so the challenge is also to understand which technology solves which type of risk.
This category helps name the problem precisely, narrow the list of relevant solutions, and distinguish technologies that may look similar at first glance. That is useful for partners and customers who already understand cybersecurity but need a clear map of the market and available portfolio.
Typical Use Cases
SAST is usually considered when an organization needs tighter control over a specific security layer within Application Security. It can complement an existing architecture, replace an outdated tool, improve visibility, or consolidate functions currently split across multiple products.
Place In The Architecture
Within the broader Application Security architecture, SAST should be assessed by how it connects to existing security and operational processes. Its practical value appears when the solution provides usable data, clear policies, understandable reporting, and integrations with existing tools.
When mapping this technology to SecTec portfolio vendors, it is important to consider not only the feature itself, but also deployment model, licensing, management level, supported platforms, and integration with adjacent areas. In a specific architecture, SAST may be a standalone platform, a capability, or part of a broader solution.
How To Assess The Technology
When selecting a solution, the most important assessment points are:
- which problem the solution covers and where its boundaries are
- whether it supports the organization's existing environment
- how it integrates with SIEM, SOAR, XDR, IAM, cloud, or ticketing
- what level of automation, reporting, and auditability it provides
- whether it reduces operational complexity or only adds another isolated console
Related Areas
Vendors From The SecTec Portfolio
Attack coverage and defensive context
MITRE ATT&CK® Enterprise version 19.1 is used as a reference model. The mapping is a SecTec expert interpretation and does not imply endorsement by MITRE.
Practical attack scenarios
- Public application or API abuseAn adversary exploits a vulnerable web application, API, client-side code, or software component for initial access and execution.
- Supply chain and trusted accessAn adversary abuses a supplier, software dependency, external access path, or trusted relationship to bypass normal controls.
- BOLA – Broken Object Level AuthorizationAn adversary changes an object identifier in an API request and gains access to data or operations belonging to another user, account, or tenant.
- BOPLA – Broken Object Property Level AuthorizationAn API exposes or allows modification of sensitive object properties that the user should not access, including excessive data exposure and mass assignment.
- BFLA – Broken Function Level AuthorizationA regular or unauthenticated user invokes an administrative or privileged API function that should not be available to them.
- SSRF – Server-Side Request ForgeryAn adversary causes a server or API to fetch an attacker-controlled address and reaches internal services, cloud metadata, or protected network targets.
- API security misconfiguration and exposed interfacesInsecure defaults, debug endpoints, broken CORS, verbose errors, or missing security headers expose data and functionality to an adversary.
- Unsafe consumption of third-party APIsAn application trusts data or redirects from a partner API more than ordinary input and propagates a supplier compromise into its own environment.
- Injection and command executionUntrusted input changes the meaning of a command, query, or template and enables data access, logic bypass, or code execution.
- Path traversal and file inclusionAn adversary manipulates a file path or imported name and reads, writes, or executes content outside the permitted directory.
- Malicious file upload and unsafe deserializationAn application accepts or processes a malicious file or serialized object and enables code execution, control bypass, or compromise of other users.
Relevant ATT&CK techniques
- T1190 · Exploit Public-Facing ApplicationPrevent, Validate
- T1195 · Supply Chain CompromisePrevent, Validate