My experience contributing to cybersecurity Open Source (SigmaHQ rule to detect AWS S3 bucket being made public)

Introduction

In my cybersecurity career journey, I have used a lot of open source tools and have always wanted to contribute back to open source. I was learning about detection engineering and came across SigmaHQ, the open source project that is the standard for writing SIEM detection rules. They also have a public rule repository from which anyone can copy a specific rule into their workflow so that their SIEM can detect that event and create an alert. This is the public rule repository: SigmaHQ/sigma.

Deciding to contribute

I was browsing the repository to understand the structure and what sort of rules existed and I wanted to find if there was any rule to detect an S3 bucket going public. The repository was neatly structured with cloud and AWS having their own folders. I checked, and no such rule existed. I knew it was a security issue if a bucket went public and definitely some security team would need to know about it so I decided to write a rule and contribute it.

Here is my pull request: github.com/SigmaHQ/sigma/pull/6118

Technical Details

This is my first open source contribution to a cybersecurity repository, but I contributed to open source in the past, so I knew the drill. And also they have a detailed CONTRIBUTING guide for anyone contributing a new rule.

So I forked their repo, cloned it locally, created a new branch and was ready to write the rule. In order to understand the rule syntax, I took a look at the other rules. And in order to write the rule, I had to create the log event and look at the log first.

So I opened my AWS account, turned on logging for S3 buckets (logging only write actions on policy changes), and then created some events (created a bucket and changed the policies front and back. There were 4 different settings under "Block Public Access". I tried some variations). After the logs had been generated, I copied a 'malicious' event's (the one where the settings were weakened) log, and used that as a reference to write the rule. You can visit the pull request to see the log I used as a reference to write the rule.

Then I started writing the rule with the .yaml syntax by filling in all the details. The complete rule is available here. I wanted it to detect whenever this part of the log

"requestParameters": {
    "publicAccessBlock": "",
    "bucketName": "another-test-bucket-186048965627-ap-southeast-1-an",
    "PublicAccessBlockConfiguration": {
        "xmlns": "http://s3.amazonaws.com/doc/2006-03-01/",
        "RestrictPublicBuckets": true,
        "BlockPublicPolicy": false,
        "BlockPublicAcls": false,
        "IgnorePublicAcls": false
    },
    "Host": "s3.ap-southeast-1.amazonaws.com"
},

had false in any of those 4 fields. This is the primary thing determining if the bucket's public access settings are being weakened. So I had to map it in the yaml part, which is done in this part of the yaml rule

selection_weaken_restrict_public_buckets:
    requestParameters.PublicAccessBlockConfiguration.RestrictPublicBuckets: 'false'
selection_weaken_block_public_acls:
    requestParameters.PublicAccessBlockConfiguration.BlockPublicAcls: 'false'
selection_weaken_block_public_policy:
    requestParameters.PublicAccessBlockConfiguration.BlockPublicPolicy: 'false'
selection_weaken_ignore_public_acls:
    requestParameters.PublicAccessBlockConfiguration.IgnorePublicAcls: 'false'
selection_status_success:
    errorCode: 'Success'
selection_status_null:
    errorCode: null
condition: selection_event_name and 1 of selection_weaken_* and 1 of selection_status_*

The merged version is not the original version I wrote. Some minor edits were made by the maintainers to improve it.

And before committing the changes I had to run the tests on the rule, and the test-running process had some missing documentation about installing another PyPI package, so I emailed the lead maintainer explaining the situation and he told me he would look into it.

Then I ran the tests and kept making edits until the tests passed and then finally committed the changes on July 8, 2026. I pushed the new branch and created a pull request.

Timeline

• 8 July, 2026: I created the pull request
• 10 July, 2026: One maintainer approved it. One more approval required to merge it
• Lots of front and back discussions and syncing my fork to upstream to keep my branch up to date
• 13 October, 2026: One more maintainer approved it. Ready to be merged.
• 21 October, 2026: One more maintainer made some changes and merged it.

So after around 4 months it was finally merged. I don't know if this is the only open source project that moves like this but this is the only one I have interacted with in a major way. It makes sense because all the maintainers are doing this in their free time and they are also super busy, like how I am writing this blog post about the merge that happened 2 weeks ago because I have been very busy travelling.

Conclusion

I am looking forward to doing more contributions to open source and if anyone is interested, please use this rule in a production environment where S3 buckets going public need to be detected and give feedback on it by creating an issue in the repository and also tag me.