How it Works

Understanding rnsec's multi-stage static analysis pipeline and architecture.

File Discovery → AST Parsing → Rule Engine → Reporting

1. File Discovery

The scanner uses fast-glob to recursively discover files:

Included: .js, .jsx, .ts, .tsx, .json, .env, .xml (AndroidManifest.xml), build.gradle, .plist (Info.plist), Podfile
Excluded: node_modules/, .git/, build outputs, IDE files, cache directories

2. AST Parsing

For JavaScript/TypeScript files, rnsec uses @babel/parser to generate Abstract Syntax Trees:

javascript
// Babel parser configuration
{
  sourceType: 'module',
  plugins: [
    'jsx',
    'typescript',
    'classProperties',
    'dynamicImport',
    'optionalChaining',
    'nullishCoalescingOperator'
  ]
}

Why AST?

  • More accurate than regex-based scanning
  • Understands code structure and context
  • Can traverse function calls, variable declarations, JSX elements
  • Reduces false positives

3. Rule Engine

The core scanning engine processes files through multiple stages:

1
Rule Registration: All 13 scanner modules register their rules
2
File Context Preparation: Each file gets AST + content + metadata
3
Rule Application: Only applicable rules run on each file
4
Finding Aggregation: Results collected and enriched with context
5
False Positive Filtering: Debug context detection, test file exclusions

4. Reporting

Results are formatted into multiple output formats:

Console

  • •Color-coded severity
  • •Grouped findings
  • •Summary statistics

HTML

  • •Interactive dashboard
  • •Severity filtering
  • •Dark theme

JSON

  • •Machine-readable
  • •CI/CD ready
  • •All metadata

Exit Codes

0Success (no HIGH severity issues)
1Failure (HIGH severity issues detected)
Previous
Quick Start
Next
Security Rules
© 2025 rnsec • Open source security
HomeDocumentationGitHub