Security review

Tooling Package Management
1

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?

2 Likes
2

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.

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.

1 Like
3

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. Perhaps it would be sufficient to translate those guidelines into rules that semgrep can use.

2 Likes
4

How many packages you will have to check?

5

Up to 20 plus dependencies. I guess those dependencies can be numerous. I think in total I would need to check 100 packages.

6

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

GitHub - JuliaComputing/semgrep-rules-julia: Julia rules for semgrep

4 Likes
7

Producing a Software Bill of Materials may be useful to you

3 Likes
8

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 will be able to ingest. That tool can already build complete SBOMs in standard formats for Julia projects.

6 Likes
9

Feel free to reach me at sushil.kumar@juliahub.com and we can demo JuliaHub platform capabilities around package management, security etc.

1 Like
10

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).

1 Like