github.com/quay/claircore@v1.5.28/docs/concepts/matcher_architecture.md (about)

     1  # Matcher Architecture
     2  `claircore/internal/matcher`
     3  `claircore/libvuln/driver`
     4  
     5  The Matcher architecture is based on a data flow application.
     6  
     7  ```mermaid
     8  graph TD
     9  	start[Libvuln.Scan]
    10  	finish[Merge into VulnerabilityReport]
    11  	start ---> RemoteMatcher & Matcher ---> finish
    12  	subgraph RemoteMatcher
    13  		ra[Filter interested packages]
    14  		api[Make API calls]
    15  		rv[Decide vulnerability]
    16  		ra --> api --> rv
    17  	end
    18  	subgraph Matcher
    19  		dbv[Check versions in-database]
    20  		ma[Filter interested packages]
    21  		adv[Retrive vulnerabilty information]
    22  		mv[Deicide vulnerability]
    23  		ma --> adv --> mv
    24  		adv -.-> dbv -.-> mv
    25  	end
    26  ```
    27  
    28  When Libvuln's Scan method is called with an IndexReport it will begin the process of matching container contents with vulnerabilities.
    29  
    30  Each configured Matcher will be instantiated concurrently. Depending on the interfaces the Matcher implements, one of the possible data flows will occur in the diagram above.
    31  
    32  The provided IndexReport will be unpacked into a stream of IndexRecord structs. Each Matcher will evaluate each record in the stream and determine if the IndexRecord is vulnerable to a security advisory in their responsible databases.
    33  
    34  Once each Matcher returns the set of vulnerabities, Libvuln will merge the results into a VulnerabilityReport and return this to the client.
    35  
    36  ## HTTP Resources
    37  
    38  ***NOTE***: Remote matchers are being considered for removal.
    39  
    40  "Remote matchers" may make HTTP requests during the matcher flow.
    41  These requests are time-bound and errors are not reported.
    42  The following are the URLs used.
    43  
    44  {{# injecturls matcher }}