Neither Angular nor React is inherently riskier. The risk comes from how many indirect packages your project pulls in and how well you control them. Count your own transitive tree, commit a lockfile, install from it in CI, and review every change to it.
Why compare frameworks at all?
The question is popular because the two projects feel different. Angular is a full framework whose parts are released together. React is a smaller library, and a typical project adds a router, state tools, build tooling and many helpers around it. People infer that more third party choices mean more risk.
That inference is only partly right. A project built on React might have fewer indirect packages than a heavy Angular one, or many more, depending on choices. We could not confirm a neutral, current study that ranks the two, so any claim that one is safer is a guess. Measure your own project instead.
What is an indirect dependency?
A direct dependency is one you list in package.json. An indirect, or transitive, dependency is one your dependencies pull in. You never chose it, usually never read it, and it still runs in your build and sometimes in your users' browsers.
The OWASP Top 10 CI/CD Security Risks lists dependency chain abuse as CICD-SEC-3. That entry is about attackers using this exact gap, for example by getting a malicious package into a place where your build will fetch it.
What does the lockfile do?
The npm documentation says package-lock.json describes the exact tree that was generated, so later installs produce identical trees regardless of intermediate dependency updates. It records an integrity value for each artifact and the place each package was resolved from. The file is meant to be committed.
In automation, npm ci installs from the lockfile and stops with an error if the lockfile and package.json disagree. It never writes to the lock. That is the behavior you want in CI, because it turns a surprise update into a failed build.
A constructed example
Two teams, one on each framework, run a count of installed packages. Team Angular finds 900. Team React finds 1,400, mostly from a build tool plugin chain. Neither number is good or bad on its own. The useful finding is different. Both teams discover that dozens of packages have a single maintainer and have not been released in years. They decide to review those first, and they replace the three they can drop. The framework choice never entered the plan.
How to check or apply this
- Count the direct and total installed packages for your project and record the numbers.
- List packages with no recent release or a single maintainer, and review them first.
- Commit the lockfile and use npm ci in CI and deployment.
- Treat any lockfile change in a pull request as code to be reviewed, not noise.
- Remove dependencies you use for one small function.
- Scan the full tree for known vulnerabilities and look at reachability, so you fix what your code can actually call.
- Re-run the count each quarter and look for growth.
Safeguard builds an SBOM and scans dependency trees with reachability analysis, and can gate pull requests on policy. The free scan at gold.safeguard.sh/scan covers up to 100 dependencies, which is enough to compare a small Angular and React project side by side.
Quick check
Does Angular have fewer dependencies than React?
It depends on the project. Count your own tree. A framework's reputation tells you little about the packages your build chain adds.
Is a lockfile enough protection?
No. It makes installs repeatable. You still need to scan the tree and review changes to it.
Sources
Last reviewed: 18 October 2026.
