pkgaudit: Static Analysis Security Testing (SAST) for R Packages

[tylerjssmith]

Submitting Author Name: Tyler Smith
Submitting Author Github Handle: @tylerjssmith
Repository: https://github.com/tylerjssmith/pkgaudit
Submission type: Pre-submission
Language: en

---

• Paste the full DESCRIPTION file inside a code block below:

Package: pkgaudit
Title: Static Analysis Security Testing (SAST) for R Packages
Version: 0.4.0
Authors@R:
    person("Tyler", "Smith", , "tylerjssmith@gmail.com", role = c("aut", "cre"),
           comment = c(ORCID = "0000-0003-4692-2206"))
Description: A static analysis tool that flags security-relevant files and code
  in R source packages for human review without executing anything it scans.
  Models package lifecycle execution semantics -- it reports not just what a
  package does, but when it runs, so code that executes on install or load is
  distinguishable from code that runs only when called. Reads every surface a
  package can execute, including 'configure' scripts, help-file macros, and
  vignettes, and states what it could not read, so a clean result can be checked
  rather than trusted. Detection rules are data, shipped in a versioned and
  hash-verified 'SQLite' database.
License: Apache License (>= 2)
URL: https://github.com/tylerjssmith/pkgaudit,
    https://tylerjssmith.github.io/pkgaudit/
BugReports: https://github.com/tylerjssmith/pkgaudit/issues
Encoding: UTF-8
Language: en-US
Roxygen: list(markdown = TRUE)
Depends:
    R (>= 4.1)
Imports:
    DBI,
    digest,
    RSQLite,
    stats,
    tools,
    utils,
    xml2,
    xmlparsedata
Suggests:
    covr,
    jsonlite,
    knitr,
    rmarkdown,
    testthat (>= 3.0.0),
    yaml
VignetteBuilder: knitr
Config/testthat/edition: 3
Config/roxygen2/version: 8.1.0
Config/Needs/website: pkgdown
Config/Needs/coverage: covr

Scope

• Please indicate which category or categories from our package fit policies or statistical package categories this package falls under. (Please check one or more appropriate boxes below):

  Data Lifecycle Packages

  • data retrieval
  • data extraction
  • data munging
  • data deposition
  • data validation and testing
  • workflow automation
  • version control
  • citation management and bibliometrics
  • scientific software wrappers
  • field and lab reproducibility tools
  • database software bindings
  • geospatial data
  • translation

  Statistical Packages

  • Bayesian and Monte Carlo Routines
  • Dimensionality Reduction, Clustering, and Unsupervised Learning
  • Machine Learning
  • Regression and Supervised Learning
  • Exploratory Data Analysis (EDA) and Summary Statistics
  • Spatial Analyses
  • Time Series Analyses
  • Probability Distributions

• Explain how and why the package falls under these categories (briefly, 1-2 sentences). Please note any areas you are unsure of:

I have checked "data validation and testing" and "workflow automation" as the
nearest fits because pkgaudit is used to validate research inputs (R packages),
but security tooling is not an explicit category, and whether pkgaudit is in
scope is the main question of this inquiry.

When searching for prior art, I noted a previous effort to develop a tool like
this for rOpenSci -- defender --
and some discussions around the same time about rOpenSci security -- like this.
It has been several years, but I wondered if there is still interest a tool like
pkgaudit. If so, I would be happy to build it toward what is needed.

If pkgaudit is out of scope, I would appreciate suggestions for a better home.
Thanks for your consideration!

• If submitting a statistical package, have you already incorporated documentation of standards into your code via the srr package?

pkgaudit is not a statistical package.

• Who is the target audience and what are scientific applications of this package?

Anyone who installs R packages from sources they have not read: individual
researchers, research software engineers and security professionals who approve
packages for regulated environments (e.g., clinical and pharmaceutical
statistical computing), and package repositories.

The scientific application is supply-chain security for the software science
runs on. R packages execute code in places reviewers rarely look -- configure
scripts at install, \Sexpr{} macros when help pages build, .onLoad() and
.onAttach(), and inline R in vignettes, for example. pkgaudit extracts this
code and scans it for security-relevant function calls and commands.

Rules have been tested at CRAN-scale (see dev/cran_survey). Every claim about
when in an R package lifecycle code may run is measured with instrumented
packages rather than taken from documentation (see dev/execution_surface).

• Are there other R packages that accomplish the same thing? If so, how does yours differ or meet our criteria for best-in-category?

To my knowledge, no R package does static security analysis of package source
code. The nearest neighbors solve different problems: oysteR and rosv check
package names and versions against known-vulnerability databases; riskmetric
(R Validation Hub) scores package risk from metadata and community metrics;
lintr and goodpractice assess code quality, not security.

• (If applicable) Does your package comply with our guidance around Ethics, Data Privacy and Human Subjects Research?

Not applicable: pkgaudit reads package source code only and collects nothing.
It does not reach the network. Reports can omit local filesystem paths (path = FALSE)
so results can be shared without disclosing usernames or directory layouts.

• Any other questions or issues we should be aware of?:

The package is designed with security in mind: it never executes what it scans
(asserted end-to-end by a test), tarball handling is fail-closed against
adversarial archives, and the rule database is reproducible byte-for-byte from
YAML sources and verified against a published SHA-256.

The biggest problem with static analysis of R is the dynamic nature of the
language. A partial solution in pkgaudit is searching not only for function
calls (e.g., system()) in an XML parse tree but also strings containing those
function names in metaprogramming functions (e.g., do.call("system")). Additional
suggestions for reducing this problem would be appreciated.

pkgaudit is not yet on CRAN; submission is planned, and I would prefer
rOpenSci review first if the package is in scope.

Use of Generative AI

• Generative AI tools were used to produce some of the material in this submission.

Claude Code was used as a code-review and drafting assistant during development:
it performed pre-release reviews that surfaced bugs (which I verified and whose
fixes are covered by tests), and helped draft documentation and tests based on
my direction. All changes are reviewed, tested, and committed by me; the
detection rules and lifecycle-phase assignments are grounded in measurement
against instrumented packages and a survey of CRAN that anyone can replicate using
code I have provided (see dev/).

[ropensci-review-bot]

Thanks for your pre-submission to rOpenSci, our editors will reply soon.

[ropensci-review-bot]

Five most similar rOpenSci packages

• drake 'A Pipeline Toolkit for Reproducible Computation at Scale' (v7.13.11, released 2024-12-04)
• stats19 'Work with Open Road Traffic Casualty Data from Great Britain' (v4.1.0, released 2026-07-31)
• EndoMineR 'Functions to mine endoscopic and associated pathology datasets' (No releases to date.)
• dbparser 'Drugs Databases Parser' (v2.2.1, released 2026-01-08)
• nlrx 'Setup, Run and Analyze 'NetLogo' Model Simulations from 'R' via
  'XML'' (v0.4.6, released 2025-11-25)

Five most similar CRAN packages

• mutator 'Mutation Testing' (v0.2.1, published 2026-08-02)
• WFC 'Workflow-Oriented Survey Weight Calibration' (v2.0.1, published 2026-08-06)
• bigbang 'Build 'Tidyverse'-Style Meta-Packages from Local Package Files' (v0.4.0, published 2026-08-19)
• opencltools ''OpenCL' Tools for R Package Developers' (v0.8.3, published 2026-08-04)
• tinytest 'Lightweight and Feature Complete Unit Testing Framework' (v1.4.3, published 2026-03-24)

---

Matches are generated by the 'pkgmatch' package, based on inverse-term frequencies; see the main function documentation for details.

[tylerjssmith]

@ropensci-review-bot check package

[ropensci-review-bot]

Thanks, about to send the query.

[ropensci-review-bot]

🚀

Editor check started

👋

[ropensci-review-bot]

Checks for pkgaudit (v0.4.0)

git hash: 130c4993

• ✔️ Package name is available
• ✔️ has a 'contributing' file.
• ✔️ uses 'roxygen2'.
• ✔️ 'DESCRIPTION' has a URL field.
• ✔️ 'DESCRIPTION' has a BugReports field.
• ✔️ Package has at least one HTML vignette
• ✔️ All functions have examples.
• ✔️ Repository has a website
• ✔️ Package has continuous integration checks.
• ✔️ Package coverage is 99%.
• ✔️ R CMD check found no errors.
• ✔️ R CMD check found no warnings.
• 👀 Some goodpractice linters failed.
• 👀 Function names are duplicated in other packages

(Checks marked with 👀 may be optionally addressed.)

Package License: Apache License (>= 2)

---

1. Package Dependencies

Details of Package Dependency Usage (click to open)

The table below tallies all function calls to all packages ('ncalls'), both internal (r-base + recommended, along with the package itself), and external (imported and suggested packages). 'NA' values indicate packages to which no identified calls to R functions could be found. Note that these results are generated by an automated code-tagging system which may not be entirely accurate.

type	package	ncalls
internal	base	1495
internal	graphics	172
internal	pkgaudit	98
internal	boot	1
internal	methods	1
imports	stats	70
imports	digest	10
imports	xml2	10
imports	DBI	7
imports	utils	6
imports	RSQLite	1
imports	xmlparsedata	1
imports	tools	NA
suggests	jsonlite	2
suggests	covr	NA
suggests	knitr	NA
suggests	rmarkdown	NA
suggests	testthat	NA
suggests	yaml	NA
linking_to	NA	NA

Click below for tallies of functions used in each package. Locations of each call within this package may be generated locally by running 's <- pkgstats::pkgstats(<path/to/repo>)', and examining the 'external_calls' table.

base

list (299), character (96), return (67), if (64), c (63), length (48), data.frame (41), is.null (40), integer (39), for (38), lapply (35), unique (27), names (26), message (24), is.na (23), nrow (22), seq_len (21), logical (20), paste0 (17), source (17), conditionMessage (15), as.integer (14), grepl (14), tryCatch (14), vapply (13), do.call (12), match (12), unname (12), seq_along (11), setdiff (11), col (10), strsplit (10), version (10), body (9), file (9), file.path (9), rep (9), eval (8), paste (8), rbind (8), sub (8), suppressWarnings (8), attr (7), nzchar (7), which (7), as.list (6), Filter (6), ifelse (6), max (6), pretty (6), trimws (6), unlist (6), all (5), close (5), as.raw (4), call (4), dir (4), file.size (4), gregexpr (4), list.files (4), min (4), missing (4), Negate (4), open (4), stop (4), sum (4), warning (4), basename (3), format (3), levels (3), nchar (3), order (3), raw (3), readBin (3), Reduce (3), regexpr (3), regmatches (3), sprintf (3), Sys.readlink (3), any (2), apply (2), as.character (2), as.logical (2), duplicated (2), emptyenv (2), gsub (2), identical (2), intersect (2), isTRUE (2), new.env (2), normalizePath (2), ordered (2), q (2), read.dcf (2), readLines (2), row (2), seq.int (2), serialize (2), sort (2), substr (2), switch (2), tolower (2), as.matrix (1), ceiling (1), class (1), cumsum (1), dir.exists (1), exists (1), file.exists (1), gzfile (1), lengths (1), options (1), pipe (1), requireNamespace (1), rev (1), rowSums (1), startsWith (1), strtoi (1), strwrap (1), substring (1), Sys.time (1), system.file (1), t (1), tabulate (1), tapply (1), tempfile (1), UseMethod (1), validUTF8 (1), writeLines (1)

graphics

lines (81), segments (46), text (35), pairs (5), frame (4), stem (1)

pkgaudit

empty (22), read_code (6), fld (5), bad (4), conform (4), new_segment (4), note (4), find_file_contexts (3), find_matches (3), find_patterns (3), analyze_segment (2), audit_package (2), extract_segments (2), find_code_contexts (2), find_indirect (2), hash_manifest (2), norm (2), parse_code (2), read_Rd_code (2), add (1), analyze_segment.default (1), analyze_segment.R (1), analyze_segment.shell (1), audit_tarball (1), ave_seq (1), build_coverage (1), determine_code_contexts (1), emit_sarif (1), export_unscanned (1), extract_segments.default (1), extract_segments.R (1), extract_segments.Rd (1), extract_segments.Rmd (1), extract_segments.Rnw (1), extract_segments.rsp (1), extract_segments.shell (1), format.pkgaudit (1), new_source (1), tar_entries (1), visit (1), visit_sexpr (1)

stats

df (28), line (27), step (9), start (3), end (2), na.omit (1)

digest

digest (10)

xml2

xml_attr (6), xml_find_all (1), xml_find_first (1), xml_path (1), xml_text (1)

DBI

dbGetQuery (6), dbConnect (1)

utils

tar (3), untar (3)

jsonlite

toJSON (2)

boot

control (1)

methods

new (1)

RSQLite

SQLite (1)

xmlparsedata

xml_parse_data (1)

NOTE: Some imported packages appear to have no associated function calls; please ensure with author that these 'Imports' are listed appropriately.

---

2. Statistical Properties

This package features some noteworthy statistical properties which may need to be clarified by a handling editor prior to progressing.

Details of statistical properties (click to open)

The package has:

• code in R (49% in 35 files) and YAML (51% in 89 files)
• 1 authors
• 4 vignettes
• no internal data file
• 8 imported packages
• 28 exported functions (median 21 lines of code)
• 194 non-exported functions in R (median 6 lines of code)

---

Statistical properties of package structure as distributional percentiles in relation to all current CRAN packages
The following terminology is used:

• loc = "Lines of Code"
• fn = "function"
• exp/not_exp = exported / not exported

All parameters are explained as tooltips in the locally-rendered HTML version of this report generated by the checks_to_markdown() function

The final measure (fn_call_network_size) is the total number of calls between functions (in R), or more abstract relationships between code objects in other languages. Values are flagged as "noteworthy" when they lie in the upper or lower 5th percentile.

measure	value	percentile	noteworthy
files_R	34	95.1
files_inst	1	71.3
files_vignettes	4	96.1
files_tests	382	100.0
loc_R	2847	93.7
loc_inst	553	81.3
loc_vignettes	719	84.0
loc_tests	4959	98.0	TRUE
num_vignettes	4	96.5	TRUE
n_fns_r	222	97.8	TRUE
n_fns_r_exported	28	86.8
n_fns_r_not_exported	194	99.0	TRUE
n_fns_per_file_r	7	89.1
num_params_per_fn	3	65.6
loc_per_fn_r	7	55.8
loc_per_fn_r_exp	21	72.2
loc_per_fn_r_not_exp	6	67.7
doclines_per_fn_exp	38	70.5
doclines_per_fn_not_exp	2	88.4
fn_call_network_size	323	94.7

---

2a. Network visualisation

Click to see the interactive network visualisation of calls between objects in package

---

3. goodpractice and other checks

Details of goodpractice checks (click to open)

3a. Continuous Integration Badges

GitHub Workflow Results

id	name	conclusion	sha	run_number	date
32777849571	Create pkgdown Website	success	130c49	33	2026-08-24
32777850128	OSV-Scanner	success	130c49	40	2026-08-24
32777849569	R CMD check	success	130c49	54	2026-08-24
32777849529	Rules DB Hash	success	130c49	11	2026-08-24
32777849701	Test Coverage	success	130c49	21	2026-08-24

---

3b. goodpractice results

Test coverage with covr

Package coverage: 99.02

Cyclocomplexity with cyclocomp

The following functions have cyclocomplexity >= 15:

function	cyclocomplexity
tar_entries	33
build_coverage	25
export_unscanned	23
find_indirect	21
determine_code_contexts	19
find_patterns	15

Static code analyses with lintr

lintr found the following 846 potential issues:

message	number of times
!all(x) is better than any(!x).	2
!any(x) is better than all(!x).	2
.Last.lib() should take one argument starting with 'lib'.	2
.onDetach() should take one argument starting with 'lib'.	4
anyNA(x) is better than any(is.na(x)).	1
Avoid implicit assignments in function calls.	4
Avoid undesirable function "setwd".	20
Avoid undesirable operator :::.	6
Compare to a constant after calling vapply() to get the full benefits of vectorization.	1
Construct file paths with file.path(...) instead of paste0(x, "/", y, "/", z).	3
Don't use nested ifelse() calls; instead, try (1) data.table::fcase; (2) dplyr::case_when; or (3) using a lookup table.	1
expect_gt(x, y) is better than expect_true(x > y).	2
expect_gte(x, y) is better than expect_true(x >= y).	1
expect_length(x, n) is better than expect_equal(length(x), n)	2
expect_lte(x, y) is better than expect_true(x <= y).	1
expect_named(x, n) is better than expect_equal(names(x), n)	2
expect_s3_class(x, k) is better than expect_true(is.(x)) or expect_true(inherits(x, k)).	1
Lines should not be more than 80 characters.	213
Remove unnecessary c() of a constant.	9
toString(.) is more expressive than paste(., collapse = ", ").	28
Unify consecutive calls to stopifnot().	5
Use " " with fixed = TRUE here.	1
Use "_" with fixed = TRUE here.	1
Use ".." with fixed = TRUE here.	1
Use "." with fixed = TRUE here.	2
Use "(source directory)" with fixed = TRUE here.	1
Use "(source tarball)" with fixed = TRUE here.	1
Use "/" with fixed = TRUE here.	1
Use "\" with fixed = TRUE here.	3
Use "an Rd comment" with fixed = TRUE here.	1
Use "attck" with fixed = TRUE here.	1
Use "collides" with fixed = TRUE here.	1
Use "could not be read in full" with fixed = TRUE here.	1
Use "could not be" with fixed = TRUE here.	1
Use "coverage incomplete" with fixed = TRUE here.	1
Use "evilPayload" with fixed = TRUE here.	1
Use "installing" with fixed = TRUE here.	1
Use "intro" with fixed = TRUE here.	1
Use "Phases:" with fixed = TRUE here.	1
Use "SECRET" with fixed = TRUE here.	1
Use <- for assignment, not ->.	10
Use <- for assignment, not =.	10
Use comparison operators (e.g.	1
Use expect_identical(x, y) by default; resort to expect_equal() only when needed, e.g.	484
Use paste(), not paste0(), to collapse a character vector when sep= is not used.	1
Use seq_along(x) instead of seq_len(length(x)).	1
Write multiple expectations like expect_false(A) and expect_false(B) instead of expect_false(A
Write multiple expectations like expect_true(A) and expect_true(B) instead of expect_true(A && B).	6

Other goodpractice checks

✖️ Documented functions have @export, @nord, or @Rdname
✖️ Avoid duplicated @PARAM documentation across functions

---

4. Other Checks

Details of other checks (click to open)

✖️ The following function name is duplicated in other packages:

• • load_rules from soilKey

---

Package Versions

package	version
pkgstats	0.2.4.1
pkgcheck	0.1.3.13

---

Editor-in-Chief Instructions:

This package is in top shape and may be passed on to a handling editor.

This package has some noteworthy properties, see 'Package Statistics' details above.

[mpadge]

Thanks @tylerjssmith, this looks like an interesting package. Our current Editor-in-Chief @adamhsparks will get back to you with views on whether the package might be in scope. Before that, one question that might help us is how your package relates to or uses the "Open Source Security Index"? In particular, the 'Oyster' package? I understand that is just one component of what you're aiming to do here, but it feels to me like that information should or could be part of pkgaudit? Could you please comment.

[tylerjssmith]

Thanks, @mpadge ! The oysteR package (and the similar rosv package) are important security tools, but they solve a different problem. Specifically, they ask if a package's dependencies have any known vulnerabilities listed in the OSS Index or Open Source Vulnerability (OSV) database. pkgaudit is focused on unknown vulnerabilities and malicious code (although discoveries it enables could feed the vulnerability databases). Additionally, the other two packages make HTTP requests while pkgaudit intentionally does not reach the network. My view is that oysteR and pkgaudit could run sequentially, with oysteR as a gate and pkgaudit as an aid to further human review. But I would be curious to know your thoughts on whether pkgaudit calling oysteR is preferable.

[mpadge]

Thanks @tylerjssmith for the thoughtful clarification. I definitely wasn't making any recommendations, and your claim that pkgaudit works entirely offline is definitely something that should be honoured! I'll hand over to @adamhsparks for now ...

[tylerjssmith]

Hi @mpadge , @adamhsparks -- I wanted to check in and see if I can provide any additional information about pkgaudit. I know this is somewhat different from many packages submitted to rOpenSci, so please let me know if I can help with the presubmission inquiry any way. Thanks!