Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Consider this: Your employees log in through Azure AD. Your contractors use Google. Your vendors authenticate via Okta. Your JSM customers are on AWS Cognito. Four identity systems. One Atlassian instance. And natively, only one identity provider is allowed. That is not a configuration oversight, it is a hard limit built into Atlassian Cloud.

Hoppscotch is an open-source API development ecosystem, similar to Postman, with over 100,000 monthly users. Two weeks ago, we set up a self-hosted instance and ran our AI pentest agents against it. They found two high-severity vulnerabilities and one medium-severity vulnerability, all present in versions up to and including 2026.2.1, and all patched in 2026.3.0: All three were responsibly disclosed and have been resolved. Note: We accidentally grouped the XSS and an Access Control issue into one report.

Microsoft 365 services are productive and reliable, but data loss can occur for various reasons. For example, a user may accidentally delete data or a ransomware infection may spread from local computers whose folders are synchronized with the cloud storage. Thus, Microsoft 365 backup is important for data protection and business continuity. With backups, you can recover the needed data and ensure uninterrupted workflows.

Here’s the reality most security teams are already living: over 80% of employees are using unapproved AI tools at work, and nearly half are actively hiding it from IT. The question facing every organization is no longer whether to adopt artificial intelligence — it’s how to secure the sensitive data flowing into it every single day. This is the governance gap.

If you’re using an Identity and Access Management (IAM) solution for safeguarding employee and customer accounts, then you must know about the IAM security risks. This is to account for the possible gaps and work on them. Identity security risks are no longer limited to not meeting checklists, but have shifted to a dynamic approach. A continuous, real-time, and risk-based approach is the new norm.

For years, cybersecurity relied on a secure network perimeter, where users were trusted once inside. This approach was effective when everything was contained in a controlled environment, but it no longer works today. Modern organizations operate across cloud platforms, SaaS, mobile devices, and distributed teams. Employees and partners connect from various locations while APIs exchange data. As a result, the traditional network boundary no longer exists.

The era of human-centric API consumption is officially ending. Over the past year, enterprises have rapidly transitioned from simply experimenting with Generative AI to deploying autonomous AI agents that drive core business operations. These agents act as digital employees. They utilize Large Language Models (LLMs) for reasoning, Model Context Protocol (MCP) servers for connectivity, and internal APIs for execution. This evolution has fundamentally altered the enterprise attack surface.

In Part 1 of this series, we discussed the CI/CD security boundary, mapped out potential attack vectors with a CI/CD threat matrix, and introduced a simple threat model focused on ideating detection workflows. In this post, we’ll apply these principles to a real-world source code management (SCM) tool example that every developer is familiar with: GitHub. In addition to threat modeling, we’ll also be taking a closer look at historical attacks on GitHub and GitHub Actions ecosystems.

Source code management (SCM) and CI/CD pipelines have become the industry standard for automating software delivery. But from the time a code change enters your SCM until it’s deployed, it’s susceptible to changes and reconfigurations that can go so far as to modify the pipeline itself. If you’re not proactively securing your CI/CD system, attackers can use it to grant themselves permissions, access secrets, and ship malicious code.

VMware costs are climbing. Broadcom’s acquisition reshuffled licensing terms, and IT teams everywhere are looking for a way out. SUSE Virtualization is one of the options getting serious attention, and for good reason. It’s an open-source, Kubernetes-native platform that runs virtual machines and containers in a single environment instead of forcing you to manage two separate stacks.