updated Github Secret Scanning fingerprint with resolved_at

[kcreddy]

What does this PR do?

Fixes bug in Github Secret Scanning alerts where events are not getting ingested into ES when an alert is resolved.

• This PR adds resolved_at timestamp into fingerprint processor to ingest the resolved events

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.

Related issues

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-07-22T17:29:13.354+0000

• Duration: 17 min 59 sec

Test stats 🧪

Test	Results
Failed	0
Passed	29
Skipped	0
Total	29

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	100.0% (3/3)	💚
Files	100.0% (3/3)	💚 2.941
Classes	100.0% (3/3)	💚 2.941
Methods	100.0% (33/33)	💚 10.269
Lines	95.754% (451/471)	👍 5.171
Conditionals	100.0% (0/0)	💚

[r00tu53r]

Changes look okay. But the test data does not test the change made. It's missing the resolved_at field and value.

[kcreddy]

@r00tu53r Any suggestion where I can add this test? Pipeline tests doesn't seem to contain _id field to show that it has changed successfully.

[r00tu53r]

@r00tu53r Any suggestion where I can add this test? Pipeline tests doesn't seem to contain _id field to show that it has changed successfully.

@kcreddy I meant testing the date processor with resolved_at.

[r00tu53r]

@kcreddy am curious why compute hash to assign it as the document id ? Why not use what elasticsearch generates ?

[kcreddy]

@r00tu53r The reason why we are using fingerprint processor to compute _id with these specific fields instead of default is to avoid duplicates. We only want to ingest events when there is some update or resolution to it. If we put it as default, it would create documents for every time the polling happens.

[kcreddy]

@kcreddy I meant testing the date processor with resolved_at

I tested that resolved_at field exists in Kibana with date and also the field can be seen in expected json log from pipeline test. I also verified the _id functionality manually in Kibana and against the value generated from _simulate API with fingerprint processor

[adriansr]

Requesting a change for performance

[adriansr]

LGTM