call graph analysis implementation; rule for dependency confusion

[scriptprivate]

• implement Zarn::Engine::CallGraph
  • build and manage the call graph
  • represent nodes (subroutines) and edges (calls between subroutines)
• modify Zarn::Engine::AST parsing
  • collect subroutine definitions and calls
  • parse all relevant Perl files
• integrate call graph into Zarn::Engine::Source_to_Sink
  • utilize call graph data
  • leverage call graph
• add tests for gall graph
  • calls within the same file
  • cross-file subroutine calls
  • external module subroutine calls
  • anonymous subroutines handling
  • overridden method detection
• optimize performance
  • cache parsed ASTs
  • lazy loading of call graph data
  • parallel processing
• update Zarn::Helper::Sarif to include new findings in SARIF reports

dependency confusion rule could be structured like this:

- id: ' '
  type: presence
  category: vuln
  name: Dependency Confusion Vulnerability
  message: |
    The project depends on a module that could be overridden by a public CPAN module,
    leading to a dependency confusion attack. Ensure that private modules use reserved
    namespaces and have proper version constraints.
  sample:
    - pattern: 'use Module::Name without version constraint'
    - pattern: 'dependency declared in cpanfile without version'
    - pattern: 'module from non-reserved namespace'
  conditions:
    - dependency_namespace: 'not reserved'
    - version_constraint: 'missing or loose'

[htrgouvea]

I have separated this discussion into two others:

Enhance ZARN to Detect Dependency Confusion Vulnerabilities: #60
Call Graph Analysis for Contextual Vulnerability Detection: #59

This way we can discuss the topics separately and with due attention.