Add FIPS compliance to agents plugin

[stafot]

Add FIPS Compliance to Agents Plugin

Summary

This PR adds Federal Information Processing Standards (FIPS) compliance support to the Mattermost Agents Plugin, enabling the plugin to be deployed in FIPS-compliant environments such as government agencies, financial institutions, and other regulated industries.

🎯 What's Changed

Core FIPS Support

• New FIPS Build Target: Added make dist-fips command to build FIPS-compliant plugin distributions
• Docker-based FIPS Builds: Uses official Mattermost FIPS-compliant Go image (cgr.dev/mattermost.com/go-msft-fips:1.24.4) for building
• Dual Distribution Support: Plugin now builds both standard and FIPS-compliant versions simultaneously

Build System Enhancements

• Updated Go Version: Upgraded from Go 1.23 to Go 1.24.0 for better FIPS compliance
• Enhanced Makefile: Added comprehensive FIPS build targets and helper functions
• Improved CI/CD: Updated GitHub Actions to build and distribute both plugin versions

CI/CD Improvements

• Dependabot Integration: Added automated dependency updates for GitHub Actions
• Enhanced Build Pipeline: CI now builds both normal and FIPS distributions
• Artifact Management: Improved artifact handling and retention policies
• Security Hardening: Pinned GitHub Actions to specific commit hashes for better security

🔧 Technical Details

FIPS Build Process

The FIPS build process:

1. Uses the official Mattermost FIPS-compliant Go image
2. Builds server binaries with FIPS-compliant cryptographic libraries
3. Creates separate distribution packages with -fips suffix
4. Maintains compatibility with existing plugin deployment workflows

New Make Targets

• make dist-fips - Builds FIPS-compliant plugin distribution
• make dist-all - Builds both standard and FIPS distributions
• make server-fips - Builds only the FIPS-compliant server binaries

File Structure

dist/ # Standard plugin distribution
dist-fips/ # FIPS-compliant plugin distribution
├── plugin-linux-amd64-fips
└── plugin.json

🚀 Usage

Building FIPS Plugin

# Build FIPS-compliant plugin
make dist-fips

# Build both versions
make dist-all

Deployment

Both plugin versions are automatically built in CI and available as release artifacts. The FIPS version can be deployed to FIPS-compliant environments while maintaining the standard version for regular deployments.

🧪 Testing

• FIPS build process tested locally
• CI pipeline updated and tested
• Both distributions build successfully
• Plugin functionality verified in both versions

📋 Checklist

• Add FIPS build support to Makefile
• Update CI workflow for dual distribution builds
• Pin GitHub Actions to specific versions
• Add dependabot configuration
• Update Go version to 1.24.0
• Test FIPS build process
• Verify plugin functionality in both distributions

🔒 Security & Compliance

This change enables the plugin to meet FIPS 140-2 compliance requirements by:

• Using FIPS-validated cryptographic modules
• Building with FIPS-compliant Go toolchain
• Maintaining separate build processes for compliance verification

�� Related

• Issues: CLD-9438, CLD-9440
• Type: Enhancement
• Breaking Changes: None
• Migration: No migration required - existing deployments continue to work unchanged

🎉 Impact

This enhancement significantly expands the plugin's deployment capabilities, making it suitable for:

• Government and military environments
• Financial services and healthcare organizations
• Any environment requiring FIPS compliance
• Enterprise customers with strict security requirements

The change maintains full backward compatibility while adding enterprise-grade compliance features.

[agarciamontoro]

Nice! I left a couple of nits below, and I have a general suggestion that can actually be applied to the other plugins PRs: can we add a check like the one proposed for the server to verify the FIPS builds?

ifeq ($(FIPS_ENABLED),true)
	cp $(GOBIN_HOST)/$(MM_BIN_NAME) $(GOBIN_HOST)/$(MMCTL_BIN_NAME) $(DIST_PATH_GENERIC)/bin # from native bin dir, not cross-compiled
	@# FIPS verification checks
	@echo "Verifying FIPS build settings..."
	$(GO) version -m $(GOBIN_HOST)/$(MM_BIN_NAME) | grep -q "GOEXPERIMENT=systemcrypto" || (echo "ERROR: FIPS binary missing GOEXPERIMENT=systemcrypto" && exit 1)
	$(GO) version -m $(GOBIN_HOST)/$(MM_BIN_NAME) | grep -q "\-tags=requirefips" || (echo "ERROR: FIPS binary missing -tags=requirefips" && exit 1)
	@echo "Verifying OpenSSL integration..."
	$(GO) tool nm $(GOBIN_HOST)/$(MM_BIN_NAME) | grep -q "func_go_openssl_OpenSSL_version" || (echo "ERROR: FIPS binary missing OpenSSL integration" && exit 1)
	@echo "FIPS verification checks passed"
else

[agarciamontoro]

I'm not opposed to this, but it seems out of scope for this PR.

[crspeller]

Agreed, please remove.

[stafot]

@agarciamontoro @crspeller While I understand dependabot is out of scope for this specific PR, I believe it should remain for the following security and maintenance reasons:

Security Posture Benefits:

• Automated vulnerability detection: Dependabot automatically identifies and creates PRs for security vulnerabilities in our GitHub Actions dependencies
• Reduces manual oversight: Eliminates the need for manual monitoring of security advisories across multiple action repositories
• Timely updates: Ensures we stay current with security patches without relying on manual processes

Operational Benefits:

• Consistency with Mattermost practices: Other Mattermost repositories use dependabot for the same security benefits
• Low maintenance overhead: Weekly schedule with limited open PRs (max 10) prevents spam while maintaining security
• Team ownership: Configured with mattermost/ai-framework as reviewers/assignees for proper oversight

The security benefits of keeping our CI dependencies current significantly outweigh the minor addition to this PR. This follows security best practices and aligns with our responsibility to maintain a secure CI/CD pipeline.

cc @esarafianou

I used this PR as opportunity to improve security posture and I did the same in the push-proxy one.

[agarciamontoro]

Why depend on clean here?

[agarciamontoro]

(I meant to Request changes, sorry)

[crspeller]

This is a lot of complexity to add to the Makefile. If we need to support fips is there some reason for having fips and non-fips builds? Why not just have all builds be fips?

If we do need to add this complexity, maybe we can have a separate makefile with all of this extra complexity contained in there.

[stafot]

We need both fips and non-fips. cc @esarafianou

[esarafianou]

@crspeller FIPS builds require a specialized runtime, which we provide in our FIPS docker image. FIPS-only would mean that customers deploying Matteermost via a tar.gz would need to have their runtime configured, even if they don't care about FIPS.

That's why we're taking the dual approach across Mattermost Server, plugins and other services.

[crspeller]

Agreed, please remove.

[agarciamontoro]

Rebased this branch on top of the v1.3.1 tag to build off the latest prepackaged version. Sorry for the force-push!

[mattermost-build]

This PR has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!

[lieut-data]

@crspeller, can we keep this open until we ship proper FIPS support in the plugin? We're using this PR to build FIPS-compliant versions with each release (a manual effort @agarciamontoro has been kind enough to juggle).

[agarciamontoro]

Merged up to the v1.4.0 tag for prepackaging for MM v11.1

[agarciamontoro]

Merged up to the v1.6.0 tag for prepackaging for MM v11.2

[agarciamontoro]

Aaaaand merged up to the v1.6.1 tag for prepackaging for MM v11.2.

[agarciamontoro]

Merged up to the v1.6.2 tag for prepackaging for MM v11.2. Changed base branch to release-1.6

[github-actions]

🤖 LLM Evaluation Results

OpenAI

✅ Overall: 20/20 tests passed (100.0%)

Provider	Total	Passed	Failed	Pass Rate
✅ OPENAI	20	20	0	100.0%

---

Anthropic

✅ Overall: 21/21 tests passed (100.0%)

Provider	Total	Passed	Failed	Pass Rate
✅ ANTHROPIC	21	21	0	100.0%

---

Azure OpenAI

✅ Overall: 17/17 tests passed (100.0%)

Provider	Total	Passed	Failed	Pass Rate
✅ AZURE	17	17	0	100.0%

---

Mistral

✅ Overall: 15/15 tests passed (100.0%)

Provider	Total	Passed	Failed	Pass Rate
✅ MISTRAL	15	15	0	100.0%

---

AWS Bedrock

✅ Overall: 18/18 tests passed (100.0%)

Provider	Total	Passed	Failed	Pass Rate
✅ BEDROCK	18	18	0	100.0%

---

This comment was automatically generated by the eval CI pipeline.

[agarciamontoro]

Merged up to the v1.7.1 tag for prepackaging for MM v11.3. Changed base branch back to master