NEW: Provide new ETW telemetry for runtime behavior, provider SarifDriver, guid c84480b4-a77f-421f-8a11-48210c1724d4.
This change proposes ETW telemetry for a range of general, useful data points:
Start/Stop for scan target retrieval (typically from disk)
Time spent in overall file enumeration phase
Time spent analyzing a discrete scan target
Time spent in aggregate for an individual rule
Notice that a failure result was generated, by rule + severity level
Also includes a general per-scan-target event and per-rule event. The intent here is that consumers can create arbitrary event ids that would allow filter/querying against them to collect arbitrary things.
Open:
I haven't added collecting data for time spent in the logging phase
We should think about the pattern of updating/extending these in client tools that build on the driver. e.g., should we simply propose these users derive from DriverEventSource and add their own events? The 'danger' here is a failure to override provider name + guid. We could protect against this by declaring an abstract class for the core event generation. All of this would require adding more code to permit injection of a customized/derived event source.
This code doesn't propose/author a test strategy yet. It is being actively tested by the sarif pattern matcher tool while we think about desing.
SarifDriver
, guidc84480b4-a77f-421f-8a11-48210c1724d4
.This change proposes ETW telemetry for a range of general, useful data points:
Open:
DriverEventSource
and add their own events? The 'danger' here is a failure to override provider name + guid. We could protect against this by declaring an abstract class for the core event generation. All of this would require adding more code to permit injection of a customized/derived event source.