Often not by default. SAST tools are strongest in mainstream application languages, and support for shell scripts, SQL files and notebooks varies by product. List what kinds of code live in your repositories, then ask each vendor which of those file types it parses.
Why the gap matters
NIST's Secure Software Development Framework describes human-readable code as including source code, scripts and any other form of code an organization deems human-readable. That is a wider net than "application languages." Build scripts, deployment helpers, database migrations and data science notebooks all fit, and they can contain real flaws such as unsafe command construction.
A scan that reports a clean result on the application folder says nothing about these files if the tool skipped them.
Inventory first
Run a simple file census across your repositories and count by extension. You will often be surprised by how much is not in the main language.
| File kind | Where flaws can hide | Questions for the vendor |
|---|---|---|
| Shell and CI scripts | Command injection from variables, unsafe downloads | Are shell files parsed, and which dialects? |
| SQL and migrations | String built queries inside procedures | Is SQL analyzed as code or ignored? |
| Notebooks | Code cells with credentials or unsafe file handling | Are cells extracted and scanned? |
| Templates | Output encoding problems | Which template engines are understood? |
| Config files | Settings, not logic | Is this a SAST feature or a different scanner? |
OWASP notes that static code analysis tools frequently cannot find configuration issues, since they are not represented in the code. Treat config scanning as a separate question.
How to test support
- Pick one real script, one SQL file and one notebook from your repositories.
- Add a known unsafe pattern to a copy of each, such as building a command from an environment variable.
- Scan and see whether the tool reports it.
- Record which file types the tool parsed, skipped or errored on.
If the tool is silent, check the scan log. Silence can mean "no issue" or "never looked." The log usually tells you which.
Options when the tool does not cover a file type
- Add a second tool built for that file type, and pay attention to the extra triage work.
- Review those files manually on pull request, using a short checklist.
- Move logic out of scripts into the main language where possible.
- Accept the gap and write it down as a known blind spot.
Any of these is fine if it is a conscious decision. The risk is a gap nobody noticed.
Make the blind spot visible
Add a line to your scan coverage report listing the file types that are not analyzed. When reviewers or customers ask about coverage, you can answer precisely. Coverage metrics for SAST are covered in a related post on how to know what is scanned.
A worked example: a file census
A team of eight developers runs a quick census across twelve repositories using file extensions. The counts are illustrative.
| File kind | Number of files | Covered by the current SAST scan |
|---|---|---|
| Main application language | 1,900 | Yes |
| Shell scripts | 140 | Not confirmed |
| SQL files and migrations | 220 | Not confirmed |
| Notebooks | 35 | No |
| Template files | 310 | Partly |
| Pipeline definitions | 60 | No |
The surprise is the number of files outside the main language. None of them is huge individually, but together they hold deployment logic, database changes and data handling, which are not trivial areas. The team uses the census to build a short list of questions for the vendor and a small test for each file kind.
Step by step: test one file kind
- Choose a real file, for example a deployment script that takes a variable and runs a command.
- Make a copy and add an unsafe pattern, such as building a command string from an input variable.
- Make another copy with the safe pattern, such as passing arguments as a list.
- Scan both. Check the log to confirm the tool parsed them.
- Record whether the unsafe copy was flagged and the safe copy was left alone.
- Repeat for each file kind on your list.
The result is a coverage table based on your own files.
Notebooks need special handling
Notebooks mix code, output and text in one file. Output cells can include data, which may contain sensitive content. Ask the vendor whether notebooks are parsed, whether only code cells are analyzed, and whether output cells are stored or transmitted. Also consider a pipeline step that strips outputs before commit, which helps both scanning and data hygiene.
SQL deserves its own question
SQL in application code is often covered, because the analysis follows strings that become queries. SQL files themselves, such as stored procedures that build dynamic statements, are a different matter. Ask whether the tool analyzes the SQL language and which database dialects it understands. If not, a review checklist for dynamic SQL in migrations and procedures is a reasonable stopgap.
Scripts are code too
NIST's Secure Software Development Framework says human readable code includes scripts and any other form of code an organization deems human readable. Shell and automation scripts often run with high privileges and handle credentials, so flaws there can matter a great deal. Typical risks include unquoted variables, commands built from input and downloads executed without verification. A short review checklist covering those items can catch many problems even without a scanner.
Deciding what to do about gaps
| Gap | Options |
|---|---|
| Tool does not parse file kind | Add another tool, or review manually |
| Tool parses it but has few rules | Ask the vendor about rule plans, add custom rules |
| Files excluded by default | Remove the exclusion if appropriate |
| Files not in repositories scanned | Add the repositories |
Record the decision and the date. An honest list of blind spots is a strength in a review, and a hidden one is a liability.
Communicating coverage
When someone asks "is our code scanned?", answer with the table. Say what is covered, what is partly covered and what is not. That level of detail builds trust, and it makes planning easier because everyone sees the same map.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which kinds of files and languages a scan reports on, then compare with your own file census.
Quick check
Should I expect SAST to cover infrastructure and config files?
Not necessarily. Many SAST tools focus on application code, and config scanning is often a separate capability. Ask.
How do I know a file was skipped?
Check the scan log or coverage report for files parsed. A file that is not listed was probably not analyzed.
Can I convert scripts into the main language to get coverage?
Sometimes, and it can help maintainability too. Weigh the effort against the risk, and keep scripts that are short and simple under review instead.
Safeguard offers asset discovery and SBOM and dependency scanning, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
