I'd LOVE to see Crowdstrike do this. The last time I dealt with the specifics of this sort of validation testing for security software was a decade and from what I saw in the RCA Delta can just keep pointing out that whatever they had worked until Crowdstrike failed to understand that the number 20 and the number 21 are not the same:
The new IPC Template Type defined 21 input parameter fields, but the integration code that
invoked the Content Interpreter with Channel File 291’s Template Instances supplied only 20
input values to match against. This parameter count mismatch evaded multiple layers of
build validation and testing, as it was not discovered during the sensor release testing
process, the Template Type (using a test Template Instance) stress testing or the first
several successful deployments of IPC Template Instances in the field.
This combined with the lack of partitioning updates, makes me draw the conclusions they're missing table stakes WRT to validation.
The new IPC Template Type defined 21 input parameter fields, but the integration code that invoked the Content Interpreter with Channel File 291’s Template Instances supplied only 20 input values to match against. This parameter count mismatch evaded multiple layers of build validation and testing, as it was not discovered during the sensor release testing process, the Template Type (using a test Template Instance) stress testing or the first several successful deployments of IPC Template Instances in the field.
This combined with the lack of partitioning updates, makes me draw the conclusions they're missing table stakes WRT to validation.