# Security review
**URL:** https://discourse.julialang.org/t/security-review/132041
**Category:** Package Management
**Tags:** security
**Created:** [September 2, 2025, 12:26am UTC](https://discourse.julialang.org/t/security-review/132041 "2025-09-02T00:26:45Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@amrods](https://discourse.julialang.org/u/amrods)
#### Post date: [September 2, 2025, 12:26am UTC](https://discourse.julialang.org/t/security-review/132041/1 "2025-09-02T00:26:45Z")
I convinced my organization to give Julia a try. I am now responsible for setting up a process to review and approve code libraries prior to inclusion to a local software repository.
I am to perform vulnerability scanning for code libraries to identify and restrict exposure to high risk code using static code analysis.
I am not sure how to even start with that. Are there any resources I can look, any packages that can do that?
---
### Author:  [@andreeco](https://discourse.julialang.org/u/andreeco)
#### Post date: [September 2, 2025, 5:22am UTC](https://discourse.julialang.org/t/security-review/132041/2 "2025-09-02T05:22:36Z")
That’s going to be a massive undertaking! But in general I believe that it would be nice to have some support for security reviews from the community for packages. This is how I did it lately with a given package (roughly and less structured):
1. I combined all the source code (/src) into a single file using the mytree function (see below).
2. I used OpenWebUI, primarily with the o4-mini model or gpt-4.1 if the
context-window or quality needed it.
3. I submitted the entire source code (/src) (including supporting
source codes or other code like manual\_documentation.md
when necessary) as the initial prompts.
4. I asked the LLM to identify potential security vulnerabilities, then
iterated through a structured review loop (roughly):
5. a. Is this actually a security issue? Can you provide justification
or evidence? (optional)
b. Propose a fix or solution.
c. Generate relevant tests.
d. Write accompanying documentation.
Thr loop should not be run only once per issue. If you repeat it, the LLM is likely to find more or refine the solution…
You will learn a ton while doing the review. If you want to make a security review without LLM, you will need a big team. Of course, depending on the company you work in, it’s possible.
```julia-auto
mytree() {
local output_file="${1:-tree_output.txt}" # default output file
name if not provided
# Clear or create output file
: > "$output_file"
echo "Generating directory tree..." | tee -a "$output_file"
tree . -I
'.git|*.sqlite3|*.ttf|*.svg|*.woff|*.woff2|*.map|*.js|*.png|*.ico|.*tom
l|*.eot' >> "$output_file" 2>/dev/null
echo -e "\n\n==== FILE CONTENTS ====\n" >> "$output_file"
find . \
-type d \( -name '.git' -o -name ' __pycache__' \) -prune -o \
-type f \
! -name '*.sqlite3' \
! -name '*.ttf' \
! -name '*.svg' \
! -name '*.woff' \
! -name '*.woff2' \
! -name '*.map' \
! -name '*.js' \
! -name '*.png' \
! -name '*.ico' \
! -name '*.toml' \
! -name '*.eot' \
-print | while read -r file; do
echo "==== $file ====" >> "$output_file"
cat "$file" >> "$output_file"
echo -e "\n" >> "$output_file"
done
echo "Done. Output saved to $output_file"
}
```
I hope this helps you.
---
### Author:  [@amrods](https://discourse.julialang.org/u/amrods)
#### Post date: [September 2, 2025, 5:32am UTC](https://discourse.julialang.org/t/security-review/132041/3 "2025-09-02T05:32:17Z")
Thanks for this! I’ve been looking into semgrep, which can automate the scanning. However, I am not a computer engineer, I’m just a user of Julia, so I’m a bit lost. I believe I will need some rule files for semgrep to compare against the package code. JuliaHub has a [white paper on secure Julia coding](https://juliahub.com/assets/pdf/Secure-Julia-Coding-Best-Practices-byJuliaHub.pdf). Perhaps it would be sufficient to translate those guidelines into rules that semgrep can use.
---
### Author:  [@andreeco](https://discourse.julialang.org/u/andreeco)
#### Post date: [September 2, 2025, 5:59am UTC](https://discourse.julialang.org/t/security-review/132041/4 "2025-09-02T05:59:47Z")
How many packages you will have to check?
---
### Author:  [@amrods](https://discourse.julialang.org/u/amrods)
#### Post date: [September 2, 2025, 6:02am UTC](https://discourse.julialang.org/t/security-review/132041/5 "2025-09-02T06:02:38Z")
Up to 20 plus dependencies. I guess those dependencies can be numerous. I think in total I would need to check 100 packages.
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [September 2, 2025, 8:01am UTC](https://discourse.julialang.org/t/security-review/132041/6 "2025-09-02T08:01:20Z")
Static analysis in Julia is generally relatively underdeveloped, and the most visible efforts have gone into performance rather than security. For example, JET.jl and Cthulhu.jl dive into the compiler’s type inference, and AllocCheck.jl hunts for heap allocations in the LLVM IR. Semgrep does have Experimental support (below Beta and Generally Available) for Julia, maybe you can start there and contribute.
[Announcing Semgrep’s experimental support for Julia | Semgrep](https://semgrep.dev/blog/2023/announcing-semgrep-s-experimental-support-for-julia/)
[GitHub - JuliaComputing/semgrep-rules-julia: Julia rules for semgrep](https://github.com/JuliaComputing/semgrep-rules-julia)
---
### Author:  [@johnh](https://discourse.julialang.org/u/johnh)
#### Post date: [September 2, 2025, 10:47am UTC](https://discourse.julialang.org/t/security-review/132041/7 "2025-09-02T10:47:23Z")
Producing a Software Bill of Materials may be useful to you
> **[GitHub - SamuraiAku/PkgToSoftwareBOM.jl: Produces a Software Bill of Materials (SBOM)...](https://github.com/SamuraiAku/PkgToSoftwareBOM.jl)**
>
> Produces a Software Bill of Materials (SBOM) describing your Julia Pkg environment. SBOM is in the SPDX format
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [September 2, 2025, 5:07pm UTC](https://discourse.julialang.org/t/security-review/132041/8 "2025-09-02T17:07:09Z")
There are typically two key parts to such a security review; static analysis is one such part. The other is _known_ vulnerability advisory tracking (like CVEs).
We’re actively working on supporting both of these at JuliaHub. In addition to the public whitepaper and open source rules, we have some additional rules we’re developing. You can reach out to us for more details.
And I’ve been pushing on advisory tracking over the past month. More to come here, but we’ll be leaning on an open source advisory format that [Trivy](https://trivy.dev) will be able to ingest. That tool can already build complete SBOMs in standard formats for Julia projects.
---
### Author:  [@s\_ku](https://discourse.julialang.org/u/s_ku)
#### Post date: [September 2, 2025, 5:10pm UTC](https://discourse.julialang.org/t/security-review/132041/9 "2025-09-02T17:10:40Z")
Feel free to reach me at [sushil.kumar@juliahub.com](mailto:sushil.kumar@juliahub.com) and we can demo JuliaHub platform capabilities around package management, security etc.
---
### Author:  [@nhz2](https://discourse.julialang.org/u/nhz2)
#### Post date: [September 2, 2025, 5:48pm UTC](https://discourse.julialang.org/t/security-review/132041/10 "2025-09-02T17:48:45Z")
The other important thing is to read all the open issues and PR’s of the packages you are directly or indirectly using, if a package has a major bug and is widely used there is a fair chance there is already an open issue or PR addressing it. This is also a good way to see if a package you are using is maintained or not (many widely used packages are not maintained).