Initial clean commit

Author: Brian Ray

.github/workflows/deploy-docs.yml

@@ -0,0 +1,73 @@
+name: Deploy Documentation to GitHub Pages
+
+on:
+  push:
+    branches:
+      - main # Or your default branch
+    paths:
+      - 'docs/**' # Trigger only on changes within the docs directory
+  workflow_dispatch: # Allows manual triggering
+
+# Required for GitHub Pages API deployment
+permissions:
+  contents: read
+  pages: write  # Needed to push to gh-pages branch
+  id-token: write
+
+# Allow only one concurrent deployment
+concurrency:
+  group: "pages"
+  cancel-in-progress: false
+
+jobs:
+  build-docs:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Set up Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: '3.x' # Use a specific version if needed, e.g., 3.11
+
+      - name: Install dependencies
+        run: |
+          python -m pip install --upgrade pip
+          # Assuming requirements are in docs/requirements.txt
+          if [ -f docs/requirements.txt ]; then
+            pip install -r docs/requirements.txt
+          else
+            echo "docs/requirements.txt not found, skipping dependency installation."
+            # Install Sphinx directly if no requirements file
+            pip install sphinx furo myst-parser sphinx-copybutton sphinx-click
+          fi
+
+      - name: Create .nojekyll file
+        run: |
+          touch docs/.nojekyll
+
+      - name: Build documentation
+        run: |
+          # Run make html inside the docs directory
+          make -C docs html
+
+      - name: Create .nojekyll file again
+        run: |
+          touch docs/_build/html/.nojekyll
+
+      - name: Upload artifact
+        uses: actions/upload-pages-artifact@v3
+        with:
+          path: docs/_build/html
+
+  deploy:
+    needs: build-docs
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    runs-on: ubuntu-latest
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4

.gitignore

@@ -0,0 +1,183 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#pdm.lock
+#   pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
+#   in version control.
+#   https://pdm.fming.dev/latest/usage/project/#working-with-version-control
+.pdm.toml
+.pdm-python
+.pdm-build/
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#  and can be added to the global gitignore or merged into this file.  For a more nuclear
+#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
+#.idea/
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# mcp SDK reference code
+python-sdk/
+secops-wrapper/
+
+# integration test auth config
+config.py
+llm.py
+config.json

CONTRIBUTING

@@ -0,0 +1,68 @@
+# Contribution Guide for Google Security Operations Community Rules
+
+Thank you for your interest in contributing to this project. This document
+contains guidelines for contributors including a style guide for writing YARA-L
+rules.
+
+Members of our community may submit YARA-L rule contributions under the
+[`rules/community`](https://github.com/chronicle/detection-rules/tree/main/rules/community) directory.
+
+## Contributor License Agreement
+
+Contributions to this project must be accompanied by a Contributor License
+Agreement (CLA). You (or your employer) retain the copyright to your
+contribution; this simply gives us permission to use and redistribute your
+contributions as part of the project. Head over to https://cla.developers.google.com/
+to see your current agreements on file or to sign a new one.
+
+You generally only need to submit a CLA once, so if you've already submitted one
+(even if it was for a different project), you probably don't need to do it again.
+
+## How to Contribute
+
+All submissions, including submissions by project maintainers, require review.
+
+Please follow the process below to contribute to this project. We've also
+[labeled](https://github.com/chronicle/detection-rules/contribute) some issues
+and pull requests with `good-first-issue` to help people who want to contribute.
+
+1.  Sign the [Contributor License Agreement](https://cla.developers.google.com/)
+1.  Familiarize yourself with this contribution guide and our rule
+    [style guide](STYLE_GUIDE.md). This will increase the likelihood that your
+    contributions will be accepted.
+2.  Open a new issue under the [Issues](https://github.com/chronicle/detection-rules/issues)
+    page of this repo, choose from one of our issue templates, and fill in all
+    of the required fields.
+3.  Create a [pull request](https://help.github.com/articles/about-pull-requests/)
+    using our pull request template and stage your proposed changes.
+      * Link your pull request to your related issue using GitHub supported
+        [keywords](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue)
+4.  Ensure that the tests associated with your pull request complete
+    successfully.
+5.  When your pull request is ready for review, add the `ready for review`
+    label to it
+6.  Someone from the Google Cloud Security team will review your pull request.
+      * Please collaborate with your reviewer to incorporate feedback &
+        suggestions into your proposed changes. For example, if a rule's logic
+        needs to be refined or the rule needs to be updated to conform to our
+        style guide.
+7.  If your proposed changes are approved, your pull request will be merged into
+    the `main` branch of this repo.
+
+We try and acknowledge all issues and pull requests within a few working days.
+
+We're happy to collaborate with contributors to make modifications
+and help get their contributions accepted. However, there may be instances where
+we're unable to accept your contribution. For example, if a rule contains
+invalid syntax or its detection use case is too broad or niche to apply to the
+environments of other Google SecOps customers.
+
+## Community Guidelines
+
+This project follows [Google's Open Source Community Guidelines](https://opensource.google/conduct/).
+
+## Style Guide for YARA-L Detection Rules
+
+Rules in this repository follow our [style guide](STYLE_GUIDE.md). For
+contributions, please familiarize yourself with this to increase the chances
+of your contributions getting accepted.