Why MCM SecOps
The problems with managing cloud security per provider and how MCM SecOps solves them.
Why MCM SecOps
Security threats do not respect provider boundaries. A misconfigured S3 bucket, a vulnerable container image in Docker Hub, a hardcoded secret in a Git repository, and an unpatched Linux host can all exist simultaneously — each detected by a different tool with its own alerting format, dashboard, and workflow. Without a unified layer, teams spend more time correlating alerts than fixing them.
Challenges & How MCM Solves Them
Each challenge below is a real friction point teams face when managing security across providers and toolchains without a unified layer.
1. Fragmented Visibility
AWS GuardDuty, Azure Defender, Docker Hub scanners, and Git hosting security alerts each live in separate consoles with no shared view. Answering "are we secure right now?" requires logging into every tool individually.
How MCM solves it: All findings from all sources are normalised into a single dashboard with unified severity, status, category, and contextual details. Teams work from one queue rather than many.
2. Alert Fatigue
Different tools produce different alert formats with no correlation. Teams struggle to prioritise what matters across dozens of simultaneous findings.
How MCM solves it: MCM normalises every finding into a consistent format with severity (Critical/High/Medium/Low) and status (Open/In Progress/Resolved), making it straightforward to triage and prioritise across sources.
3. Incomplete Coverage
Cloud-native tools cover cloud resources but ignore container images, source code, and host machines — leaving large attack surfaces unmonitored.
How MCM solves it: MCM integrates multiple scanning engines to cover every layer: AWS CloudTrail and the Azure Activity Log for cloud activity, Trivy for container images in Docker Hub, Trivy scanning for GitHub, GitLab, and Bitbucket repositories, and the Elastic Agent on Linux hosts for runtime and network security.
4. No Triage Workflow
Findings pile up with no consistent way to decide what is a real problem, what is accepted risk, and what needs escalating — and no record of who decided what.
How MCM solves it: For runtime and network findings, reviewers can suppress, escalate, resolve, or reopen a finding with a note, and every decision is kept in the finding's history. A review queue shows what still needs attention.
5. Manual Scanning
Container registries and code repositories require separate tool configurations, credentials, and schedules per source.
How MCM solves it: All scan sources — registries, repositories, and hosts — are configured once in MCM. A unified daily or weekly schedule runs across all of them, or any scan can be triggered on demand from the same interface.
6. No Unified Audit
Producing evidence for security audits means pulling reports from multiple tools and manually assembling a compliance picture.
How MCM solves it: All findings are centralised in MCM with full status tracking. Audit evidence is a single export rather than a manual assembly job across multiple tool dashboards.
MCM vs Managing Security Individually
| Aspect | Individual Tools | MCM SecOps |
|---|---|---|
| Coverage | Separate tools per layer (cloud, container, code, host) | Unified scanning across all layers |
| Onboarding | Per-tool credentials and API configuration | Single UI for registries, repos, and hosts |
| Findings | Separate alert streams, different formats | Correlated dashboard with unified severity and status |
| Triage | Ad-hoc, tracked in spreadsheets | Suppress, escalate, resolve, or reopen findings with history |
| Scheduling | Different cadences per tool | Unified daily/weekly schedule or on-demand |
| Audit evidence | Pull reports from multiple tools manually | Centralised findings with status tracking |
Features
| Feature | Description |
|---|---|
| Cloud resource scanning | Monitor AWS CloudTrail and the Azure Activity Log for IAM changes, root access, policy violations, and suspicious activity — including organization-wide monitoring across all accounts of an AWS Organization |
| Container image scanning | Scan Docker Hub images for CVEs, secrets, and misconfigurations via Trivy |
| Host scanning | Agent-based runtime and network monitoring on Linux hosts (Ubuntu, Debian, RHEL, CentOS, Amazon Linux, SUSE, Rocky Linux, AlmaLinux, Oracle Linux) through the Elastic Agent |
| Git repository scanning | Scanning across GitHub, GitLab, and Bitbucket repositories for secrets, dependency vulnerabilities, and IaC misconfigurations via Trivy |
| Finding review | Triage runtime and network findings by suppressing, escalating, resolving, or reopening them with a note, with a history of each decision |
| Unified findings dashboard | All findings normalised into a single view with severity (Critical/High/Medium/Low) and status (Open/In Progress/Resolved) |
| Scheduled and on-demand scans | Configure daily or weekly scan schedules, trigger a scan manually, or start scans automatically after a discovery run |
| Finding categories | Classify findings as Misconfiguration, Secrets, CVE, Best Practice violation, or other categories |
| Rich contextual detail | Each finding includes source context: repo branch, image tag, file path, CVE reference, or CVSS score |
Code Scanning
MCM SecOps scans your GitHub, GitLab, and Bitbucket repositories using Trivy to detect security issues directly in source code. Scans cover:
- Hardcoded secrets — API keys, passwords, tokens, and certificates committed to the repository
- Dependency vulnerabilities — known CVEs in
package.json,requirements.txt,go.mod, and other manifest files - IaC misconfigurations — insecure settings in Terraform, CloudFormation, and Dockerfile definitions
Each finding includes the file path, line number, severity, CVE reference (where applicable), and the branch it was found on. Scans run on a configurable schedule or can be triggered manually from the MCM interface.
What you get: Security visibility into the code your team ships — catching secrets and vulnerabilities before they reach production, without adding a separate SAST tool to your pipeline.
Audit Log Scanning
MCM reads your AWS CloudTrail logs straight from the S3 bucket where they are stored, and your Azure subscription's Activity Log through Azure's own monitoring service, to detect suspicious or policy-violating activity, including across every account of an AWS Organization. Nothing is installed on your hosts and, on Azure, nothing is created in your subscription. Detections include:
- Root account usage and failed login attempts
- IAM policy changes and privilege escalation
- Unusual API call patterns and geographic anomalies
- Security group or firewall rule modifications
Each event is rated by severity and tagged with the matching MITRE ATT&CK technique. Findings are normalised into the unified SecOps findings dashboard with the same severity levels and status workflow as all other finding types.
What you get: Continuous monitoring of cloud control-plane activity that would otherwise require a dedicated SIEM — surfacing insider threats, credential compromise, and misconfiguration changes as they happen.
Container Scanning
MCM scans container images in Docker Hub using Trivy to identify vulnerabilities and misconfigurations before containers run in production. Scans cover:
- OS package CVEs — known vulnerabilities in base image packages (e.g. OpenSSL, glibc)
- Application dependency CVEs — vulnerable libraries bundled in the image layers
- Secrets in layers — credentials or tokens accidentally included in image build steps
- Dockerfile misconfigurations — running as root, exposed sensitive ports, missing security options
Each finding includes the image name, tag, layer, CVE ID, CVSS score, and fix version where available.
What you get: A clear picture of the vulnerability surface of your container fleet before images are deployed — prioritised by severity so teams focus on what matters most first.
Runtime & Network Security of Host
MCM deploys the Elastic Agent on Linux hosts to provide continuous runtime and network security monitoring, with installers that work across supported Linux distributions. Coverage includes:
- Runtime threat detection — alerts on suspicious behaviour on running hosts, such as unexpected processes, privilege changes, and sensitive file access
- Network monitoring — watches connections to and from the host and flags unusual traffic patterns
- Agent health — see which hosts have the agent installed and healthy, with dedicated pages for runtime alerts, network activity, audit events, and agents
All host findings flow into the same unified SecOps dashboard, giving you a consolidated view of cloud, code, container, and host security in one place.
What you get: Operating system-level security visibility for Linux hosts that cloud provider tools cannot reach — detecting threats on the actual machines running your workloads.