CRAN expects submitted packages to pass R CMD check with the as-cran option, to have clear copyright and licensing, and to avoid malicious or anti-social behavior. These are policy and quality checks run by volunteers. They are not a security audit of every line of code.
What the policies say
The CRAN repository policy and the submission checklist set out the rules. Several are directly relevant to a supply chain reader.
- Ownership of copyright and intellectual property for all components must be clear and unambiguous, including what the author states in the DESCRIPTION file.
- Source packages must provide source, or something easily converted back to source, for all components.
- Code and examples should never do anything that might be regarded as malicious or anti-social.
- Security provisions must not be circumvented, for example by not verifying SSL or TLS certificates.
- Use of external resources such as websites must be kept to a minimum, and packages using the Internet should fail gracefully when a resource is unavailable.
- Packages are expected to pass the check with the as-cran option, or authors are asked to fix and resubmit.
The checklist also asks for a useful Description field and, preferably, an Authors@R field that lists all authors and copyright holders, with ORCID identifiers where available.
What this means for a user
Think of acceptance as a gate for hygiene, not a guarantee of safety. The policies forbid circumventing security and acting maliciously, and reviewers apply that rule, but a reviewer cannot be expected to find every subtle vulnerability in compiled code or in a dependency chain.
| Question | CRAN acceptance answers it? |
|---|---|
| Does the package build and pass checks? | Yes, that is the core gate |
| Is licensing and ownership stated? | Yes, policy requires clarity |
| Is the code free of vulnerabilities? | No, not promised |
| Will the package stay maintained? | No, see below |
| Are its dependencies safe? | Not audited for you |
A practical intake routine
- Read the DESCRIPTION: authors, license, maintainer, and listed dependencies.
- Check for compiled code and bundled libraries, since these carry most of the memory safety risk.
- Look at how often the package is updated and whether issues get answered.
- Record the exact version in your lockfile. See the renv lockfile guide.
- Scan the project for known vulnerable packages. See scanning R projects.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how direct and transitive dependencies are listed, which is the part registry review does not cover for you.
Quick check
Is a package on CRAN safe to install without further checks?
Not automatically. CRAN policy forbids malicious behavior and requires checks to pass, but it does not promise the absence of vulnerabilities. Review and scan like any other dependency.
Does CRAN require ORCID identifiers?
The submission checklist says to preferably provide an Authors@R field and to add an ORCID where a person has one. It is a recommendation, not a blanket requirement.
Safeguard's SBOM and dependency scanning covers dependency inventories, and a free scan is available.
Sources
Last reviewed: 19 October 2026.
