sophos: fix log config indentation

[efd6]

What does this PR do?

Fixes indentation in the log config yml/hbs.

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.

Author's Checklist

• [ ]

How to test this PR locally

Related issues

• Fixes Sophos Integration v2.11.0 Can't Create Policy due to Error: Bad Indentation of a Mapping Entry #6690

Screenshots

[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: 2023-07-03T04:35:35.908+0000

• Duration: 19 min 34 sec

Test stats 🧪

Test	Results
Failed	0
Passed	31
Skipped	0
Total	31

🤖 GitHub comments

Expand to view the 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% (2/2)	💚
Files	100.0% (13/13)	💚 2.865
Classes	100.0% (13/13)	💚 2.865
Methods	98.901% (90/91)	👍 6.707
Lines	93.776% (1808/1928)	👍 1.947
Conditionals	100.0% (0/0)	💚

[elasticmachine]

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

[bhapas]

LGTM.

Just thinking if we can catch these kind of errors at build / check process? Can package-spec catch these errors

cc: @andrewkroh

[andrewkroh]

How can we improve here? Why didn't this get caught by a test case? Is this missing a system test for the log input? Is there any validation we can propose in package-spec to catch this? 🤔

[andrewkroh]

Just thinking if we can catch these kind of errors at build / check process? Can package-spec catch these errors

@bhapas It seems we are thinking the same way.

[efd6]

How can we improve here? Why didn't this get caught by a test case? Is this missing a system test for the log input? Is there any validation we can propose in package-spec to catch this? 🤔

This did not get caught because the document is not a yaml document until it has been template-expanded.

I was thinking about how to catch this in testing and the only thing I could come up with given the constraint of having a document that is essentially free-form — mod the handlebars syntax requirements — would be to have EP expand the template with valid-for-type values and confirm that the yaml is valid.

[efd6]

An approach could be to check whether there is any /^\t/ in the hbs files. This would under-report. A more brutal approach would be to check whether there are any /^\s*\t+\s*/; this would over-report since it is valid to have tabs in text.

[elasticmachine]

Package sophos - 2.11.1 containing this change is available at https://epr.elastic.co/search?package=sophos

[andrewkroh]

would be to have EP expand the template with valid-for-type values and confirm that the yaml is valid.

That's similar to what I was thinking in the general case to validate handlebars and the yaml.

But I think in this particular case of sophos the integration is missing a system test for log. It has one for the other input types, but not log.