モバイルデバイス管理（MDM）とは、組織が従業員のモバイルデバイスを保護、管理、監視するために使用するソフトウェアの一種です。 Jamf、Kandji、Microsoft Intune などのツールは、IT チームに対し、全デバイス上で承認されたすべてのアプリケーションに対する可視性と制御を提供します。SOC 2 や ISO 27001 といったコンプライアンスフレームワークにおいて、MDM は、デバイスの管理状況を証明し、データセキュリティを確保するための重要な要素となることがよくあります。MDM を導入済みであれば、おめでとうございます。2012 年の BYOD セキュリティ課題を解決したことになります。
問題は、現代の開発者の攻撃対象領域が、MDMが対応するように設計された範囲を静かに超えてしまっていることです。開発者のマシンが侵害される際、その侵入経路がOSやIT部門が導入したシステムであることはほとんどありません。 最近、ある開発者のデバイスにインストールされた悪意のあるVS Code拡張機能により、攻撃者がGitHubに侵入し、数千もの内部リポジトリが公開される事態が発生しました。それ以前にも、「Mini Shai-Hulud」と呼ばれるnpmワームが、開発者のマシンから認証情報を盗み出し、MistralやTanStackを含む160以上のパッケージを侵害しました。開発者のデバイスは攻撃者にとって最大の標的であるにもかかわらず、MDMは依然としてその実態を把握できていません。
この記事では、MDMの死角がどこにあるか、EDRでも見落とされがちな点、そして開発者用デバイスを確実に保護する方法について解説します。
MDMの仕組みと、その限界
MDMはOS層およびアプリケーション層で動作します。具体的には、OSの更新プログラムの配信、パスワードポリシーの適用、証明書の管理、ディスク暗号化の実施、インストール済みアプリケーションのインベントリ管理、そして紛失や盗難に備えてリモートワイプ機能を用意しておくといったことが挙げられます。App Storeやエンタープライズソフトウェアの展開、管理コンソール経由で配信される署名付きバイナリなど、標準的なOSメカニズムを通じて展開されるアプリケーションに対しては、MDMは効果的に機能します。
以下に挙げる死角は、すべて同じ根本的な原因に起因しています。npm や pip といったパッケージマネージャーは、ユーザー空間のツールです。これらは、MDMとは一切関係のないレジストリからソフトウェアを取得し、MDMが可視化できないプロジェクトディレクトリにインストールします。このプロセスは、開発者のシェルで実行されるコマンドによってトリガーされます。マーケットプレイスを通じてインストールされるIDE拡張機能、ブラウザプラグイン、AIツールについても同様です。これらはいずれも、MDMが監視するOSレベルのインストールメカニズムを経由することはありません。
MDMに見落とされがちな点
パッケージレジストリ
MDMは、IT部門が承認・展開したアプリケーションを把握していますが、開発者がパッケージレジストリから何を取得しているかについては可視性がありません。これは重要な問題です。なぜなら、パッケージはインストール時にライフサイクルフックを通じてコードを実行するため、セキュリティツールが反応する余地がないからです。 悪意のあるパッケージがペイロードを実行する頃には、開発者のマシンから認証情報をすでに盗み出している可能性があります。Mini Shai-Huludワームはまさにこの手口で、npmやGitHubのトークンを密かに盗み出し、それらを使用してチェーン上の次のパッケージの悪意のあるバージョンを公開しました。
AIコーディングツールは、この問題に新たな側面をもたらしました。AIモデルは存在しないパッケージ名を誤って提案することがあり、攻撃者は誰にも気づかれる前にそれらを登録してしまいます。開発者がAIコーディングツールに依存関係の追加を依頼すると、ツールは自信満々に存在しないパッケージを提案しますが、その時点で攻撃者はすでにnpm上でその名前を、悪意のあるペイロードを仕込んで確保しているのです。いずれにせよ、MDMはこのインストールを検知できません。
ブラウザ拡張機能
開発者の業務の多くはブラウザ上で行われているにもかかわらず、ほとんどのセキュリティチームはこれに対して十分な懸念を抱いていません。GitHub、クラウドコンソール、CI/CD 、社内ツールなどは、一日中アクセス可能な状態で認証されたまま放置されています。 その環境の上にはブラウザ拡張機能が乗っており、多くの人は何も考えずにその権限を許可してしまいます。すべてのサイトにアクセスできる拡張機能は、認証済みセッションやページを通過する通信データを含め、ブラウザが読み込むあらゆる情報を読み取ることができます。MDM（モバイルデバイス管理）は、こうした状況のすべてを把握できていません。
今年初めに発生したVercelのセキュリティ侵害事件は、こうした問題がどれほど急速に深刻化するかを示しました。 Vercelの従業員がChrome拡張機能をインストールし、自身のGoogle WorkspaceへのOAuthアクセス権を付与しました。その後、Context.aiの従業員の端末が情報窃取型マルウェアに感染した際、攻撃者は保存されていたOAuthトークンを発見し、それを利用してVercelの内部システムにアクセスしました。この悪意のある拡張機能は、IT部門ではなく開発者自身によってインストールされたものであり、付与された権限を使って何を行っていたかはMDMからは全く把握できなかったため、MDMではこれを検知することができませんでした。
ブラウザ拡張機能の管理が特に難しいのは、更新がユーザーに通知されずに実行されるためです。インストール時には安全だった拡張機能でも、一夜にして悪意のある更新が配信される可能性があり、自動更新を有効にしているユーザー全員に自動的に適用されてしまいます。2024年に発生したCyberhavenの侵害事件は、まさにこのパターンに当てはまります。開発者アカウントに対するフィッシング攻撃により、悪意のある更新が全ユーザーに配信され、誰かがそれに気付くまでの24時間にわたり、その状態が続いていました。
IDE拡張機能
開発者がインストールするあらゆるソフトウェアの中で、VS Codeのプラグインは最も「核心的な部分」に近い位置にあります。開発環境内で直接動作するため、マシン上の他のほぼすべてのものよりも、開発者の作業内容を詳細に把握することができます。ブラウザ拡張機能と同様に、IDE拡張機能も開発者自身によってインストールされ、更新はバックグラウンドで行われ、MDMの監視範囲には一切入りません。その違いは、IDE拡張機能がソースコードや認証情報を閲覧できる点にあります。
GitHubへの不正アクセス事件が、この事実を如実に示しました。侵入の入り口となったのは、Nx Console VS Code拡張機能でした。これは、220万回のインストール実績を持つ認証済みパブリッシャーの拡張機能でしたが、Visual Studio Marketplace上でわずか18分間だけ侵害されました。 VS Codeは、エディタがギャラリーとのやり取り、サイドバーの表示、マーケットプレイスの検索、バックグラウンドでのメタデータ取得を行うたびに拡張機能の更新を確認するため、その18分間の間にエディタを開いていた開発者には、プロンプトや警告なしに自動的に悪意のあるバージョンが配信されてしまいました。GitHubの内部リポジトリ3,800件が流出しました。MDMは、これらを検知する上で何の役割も果たしませんでした。
AIツール、MCPサーバー、およびコーディングエージェント
AIコーディングツールは、今や開発者の業務において欠かせない存在となっています。Cursor、GitHub Copilot、Claude Code、Windsurfといったツールは、何がインストールされるのか、データがどこに送信されるのかを人間が確認することなく、自動的に処理を行ってしまうことがよくあります。MDMに依存しているセキュリティチームは、こうした状況のほとんどを把握できていないのが実情です。
MCPサーバーは、AIアシスタントに外部サービスと連携する機能を与えることで、この機能をさらに拡張します。そして、他の依存関係と同様に、これらも侵害される可能性があります。2025年9月、npmパッケージ「postmark-mcp」が、実環境において確認された最初の悪意のあるMCPサーバーとなりました。このサーバーは、送信されるすべてのメールを、攻撃者が制御するアドレスに密かにCCで転送していました。このMCPサーバーには、バックドアが組み込まれた16番目のバージョンが出るまで、15の正常なバージョンが存在していました。
これはまったく新しい攻撃対象領域であり、ほとんどのセキュリティチームはまだこれを監視していません。
EDRについてはどうでしょうか？
セキュリティチームがMDMだけでは不十分だと気づいたとき、通常、次に導入されるのがエンドポイント検知・対応（EDR）です。CrowdStrikeやSentinelOneといったツールは、プロセスの異常な動作、ファイルシステムの不審な変更、およびコマンド＆コントロールへのコールバックを監視します。マルウェアがマシン上でアクティブに実行されている場合、EDRであればそれを検知できる可能性は十分にあります。
問題は、EDRが実行後に動作する点にあります。EDRが何かを検知できる段階になる頃には、悪意のあるインストール後フックはすでに実行され、認証情報はすでに盗み出されており、Mini Shai-Huludの場合では、盗まれたトークンがすでに次の波の侵害済みパッケージを公開するために使用されていたのです。EDRは「npm install」を検知しません。EDRには、通常の開発活動のように見えるプロセスが映るだけです。その時点で、すでに手遅れなのです。
ギャップを埋める方法
MDMや従来のEDRがなくなることはないし、そうあるべきでもない。重要なのは、これらを基盤として、もともと想定されていなかった開発者特有の攻撃対象領域をカバーする制御機能を重ねていくことだ。
パッケージの最低年齢制限を適用する
新しいパッケージには高いリスクが伴います。公開から48時間以上経過するまで利用できないというポリシーを導入すれば、同日中のタイポスクワッティングや、急速に拡散するマルウェアキャンペーンが開発者の環境に到達するのを防ぐことができます。Mini Shai-HuludキャンペーンやAxiosへの攻撃では、いずれもシステムが侵害されてから数時間以内に公開されたパッケージを通じてペイロードが配信されました。 48時間の最低公開期間ポリシーがあれば、これらは開発者のマシンに到達する前に両方とも阻止できたはずです。なお、これはnpmおよび一般的なソフトウェア依存関係パッケージに適用される点に留意してください。自動更新される拡張機能には効果がなく、これは別の問題となります。
デフォルトでインストール後のスクリプトをブロックする
ほとんどのチームは設定を行う --スクリプトを無視 インストール後のフックが自動的に実行されないよう、パイプラインに設定している。開発者のマシンに対しても同様のデフォルト設定を適用しているケースは少ない。Mini Shai-Huludワームは、インストール後のフックを通じてペイロードを配信した。開発者のローカル環境でインストールスクリプトがデフォルトで実行される場合、そこに脆弱性が存在する。設定は ignore-scripts=true 世界的に .npmrc ファイルには記載されていますが、ツールを使わずにチーム全体で一貫してこれを徹底させるのは困難です。
ブラウザおよびIDEの拡張機能を監査する
多くのセキュリティチームは、開発者環境全体でどのVS Code拡張機能やブラウザプラグインがインストールされているのか、把握できていません。何がインストールされているか、誰がインストールしたか、そして最近更新されたかどうかを可視化する必要があります。GitHubとVercelでのセキュリティ侵害は、いずれも誰も監視していなかった拡張機能が原因で発生しました。承認済みリストを作成し、それを一元的に適用することが目標ですが、これは大規模な環境では手作業で行うことは不可能です。
AIコーディングツールが何をインストールするかを確認する
開発者たちは、Cursor、Claude Code、Copilot、そして増え続けるMCPサーバーを利用していますが、多くの場合、セキュリティチームはその事実を把握していません。「シャドウAI」は現実の問題です。目に見えないものを管理することはできません。また、人間の確認なしに自律的にパッケージをインストールするAIツールは、攻撃対象領域の重要な一部となっているのです。
開発者向け専用エンドポイントツールを使用する
上記の対策は、大規模な環境で一貫して実施するのが困難であるか、あるいは攻撃対象領域のすべてを網羅できていない場合があります。専用の開発者向けエンドポイントツールは、管理対象の全マシンにおいて、デバイスレベルでのパッケージのインストール状況、拡張機能の動作、およびAIツールの挙動を監視するために特別に設計されています。
Aikido 機器の保護 既存のMDMを通じて展開され、パッケージレジストリ、IDE拡張機能、ブラウザプラグイン、AIツールマーケットプレイスを網羅しています。開発者が実行すると npm i axios 最新バージョンは1時間前に公開されましたが、Device Protectionは「公開から48時間以上経過している」というポリシーを満たす最新バージョンに自動的に切り替わります。安全なインストールは中断されることなく行われます。悪意のあるものは、マシンに到達する前にブロックされます。
これは、1日あたり10万件以上の不審なプロジェクトを分析する「Aikido 」を基盤としています。本格的な導入を行わずに始めたい場合は、オープンソースの「Safe Chain」が最適な出発点となります。Shai-Hulud、TeamPCP、Axiosの各攻撃が発生していた期間にこれを実行していた場合、保護されていたことになります。
MDMは必要だが、十分条件ではない
これは、MDMを置き換えるべきだという主張ではありません。MDMは本来の目的を果たしており、デバイスのコンプライアンス確保、証明書管理、監査人への管理体制の証明という点では、依然として最適なツールです。しかし、開発者のマシンはいつの間にか別の種類のエンドポイントとなり、MDMが設計された当時は存在しなかった脅威の標的となっています。
ほとんどのセキュリティチームが問うべきなのは、MDMポリシーとパッケージのインストールとの間に何が起きているのか、ということです。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "TechArticle",
"@id": "https://www.aikido.dev/blog/what-mdm-cant-protect-on-developer-machines#article",
"headline": "What MDM Can't Protect on Developer Machines (And What To Do About It)",
"description": "MDM tools like Jamf and Kandji are essential but they don't see npm installs, IDE extensions, or AI coding tools. Here's what's actually unprotected on your developer machines and how to close the gap.",
"url": "https://www.aikido.dev/blog/what-mdm-cant-protect-on-developer-machines",
"datePublished": "2026-05-28T00:00:00Z",
"dateModified": "2026-05-28T00:00:00Z",
"inLanguage": "en-US",
"timeRequired": "PT10M",
"keywords": [
"MDM",
"Mobile Device Management",
"developer endpoint security",
"npm security",
"VS Code extension security",
"IDE extension security",
"browser extension security",
"MCP server security",
"EDR limitations",
"supply chain attacks",
"slopsquatting",
"Aikido Device Protection",
"developer device security",
"endpoint protection",
"Jamf",
"Kandji",
"Microsoft Intune",
"CrowdStrike",
"SentinelOne",
"postinstall hooks",
"ignore-scripts",
"Safe Chain",
"Aikido Intel"
],
"articleSection": "Security Guides",
"author": {
"@type": "Person",
"@id": "https://www.aikido.dev/authors/nicholas-thomson",
"name": "Nicholas Thomson",
"jobTitle": "Senior SEO & Growth Lead",
"url": "https://www.aikido.dev/authors/nicholas-thomson",
"worksFor": {
"@type": "Organization",
"name": "Aikido Security",
"url": "https://www.aikido.dev"
},
"sameAs": [
"https://www.linkedin.com/",
"https://x.com/"
]
},
"publisher": {
"@type": "Organization",
"@id": "https://www.aikido.dev#organization",
"name": "Aikido Security",
"url": "https://www.aikido.dev",
"logo": {
"@type": "ImageObject",
"url": "https://www.aikido.dev/logo.png"
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://www.aikido.dev/blog/what-mdm-cant-protect-on-developer-machines"
},
"about": [
{
"@type": "DefinedTerm",
"name": "Mobile Device Management",
"description": "A type of software used by organizations to secure, manage, and monitor employee devices, operating at the OS and application layer."
},
{
"@type": "DefinedTerm",
"name": "Endpoint Detection and Response",
"description": "Security tooling that detects and responds to threats after they are executing on a device, watching for anomalous process behavior and file system changes."
},
{
"@type": "DefinedTerm",
"name": "Slopsquatting",
"description": "An attack where threat actors register package names that AI models tend to hallucinate, waiting for developers to install them on an AI coding tool's recommendation."
}
],
"mentions": [
{
"@type": "SoftwareApplication",
"name": "Jamf",
"url": "https://www.jamf.com"
},
{
"@type": "SoftwareApplication",
"name": "Kandji",
"url": "https://www.kandji.io"
},
{
"@type": "SoftwareApplication",
"name": "Microsoft Intune",
"url": "https://learn.microsoft.com/en-us/mem/intune/"
},
{
"@type": "SoftwareApplication",
"name": "CrowdStrike",
"url": "https://www.crowdstrike.com"
},
{
"@type": "SoftwareApplication",
"name": "SentinelOne",
"url": "https://www.sentinelone.com"
},
{
"@type": "SoftwareApplication",
"name": "Aikido Device Protection",
"url": "https://www.aikido.dev/protect/device-protection"
},
{
"@type": "SoftwareApplication",
"name": "Aikido Safe Chain",
"url": "https://github.com/AikidoSec/safe-chain"
},
{
"@type": "SoftwareApplication",
"name": "Aikido Intel",
"url": "https://intel.aikido.dev"
}
],
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": ["h1", "h2", "p"]
}
},
{
"@type": "WebPage",
"@id": "https://www.aikido.dev/blog/what-mdm-cant-protect-on-developer-machines",
"url": "https://www.aikido.dev/blog/what-mdm-cant-protect-on-developer-machines",
"name": "What MDM Can't Protect on Developer Machines",
"description": "MDM tools like Jamf and Kandji are essential but they don't see npm installs, IDE extensions, or AI coding tools. Here's what's actually unprotected on your developer machines and how to close the gap.",
"inLanguage": "en-US",
"isPartOf": {
"@type": "WebSite",
"url": "https://www.aikido.dev",
"name": "Aikido Security"
},
"breadcrumb": {
"@id": "https://www.aikido.dev/blog/what-mdm-cant-protect-on-developer-machines#breadcrumb"
},
"primaryImageOfPage": {
"@type": "ImageObject",
"url": "https://www.aikido.dev/images/what-mdm-cant-protect-on-developer-machines.png"
}
},
{
"@type": "BreadcrumbList",
"@id": "https://www.aikido.dev/blog/what-mdm-cant-protect-on-developer-machines#breadcrumb",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://www.aikido.dev"
},
{
"@type": "ListItem",
"position": 2,
"name": "Blog",
"item": "https://www.aikido.dev/blog"
},
{
"@type": "ListItem",
"position": 3,
"name": "What MDM Can't Protect on Developer Machines",
"item": "https://www.aikido.dev/blog/what-mdm-cant-protect-on-developer-machines"
}
]
},
{
"@type": "Organization",
"@id": "https://www.aikido.dev#organization",
"name": "Aikido Security",
"url": "https://www.aikido.dev",
"logo": {
"@type": "ImageObject",
"url": "https://www.aikido.dev/logo.png"
},
"sameAs": [
"https://www.linkedin.com/company/aikido-security",
"https://x.com/AikidoSecurity",
"https://github.com/AikidoSec"
]
},
{
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "What does MDM not protect against?",
"acceptedAnswer": {
"@type": "Answer",
"text": "MDM operates at the OS and application layer and cannot see package manager installs (npm, pip), IDE extensions, browser plugins, or AI coding tool activity. These happen in user space through channels MDM has no hooks into."
}
},
{
"@type": "Question",
"name": "Can MDM protect developer machines?",
"acceptedAnswer": {
"@type": "Answer",
"text": "MDM can enforce OS-level policies, manage certificates, and track IT-deployed applications on developer machines. However, it cannot monitor package installs, IDE extensions, browser plugins, or AI tools, which represent the primary modern attack surface for developer devices."
}
},
{
"@type": "Question",
"name": "What is the difference between MDM and EDR for developer security?",
"acceptedAnswer": {
"@type": "Answer",
"text": "MDM manages devices at the OS and application layer, while EDR detects threats after they are already executing. Neither tool was built to understand developer-specific behavior like package installs, IDE extensions, or MCP servers. Dedicated developer endpoint tooling is needed to cover this gap."
}
},
{
"@type": "Question",
"name": "What is slopsquatting?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Slopsquatting is an attack where threat actors register package names that AI coding tools tend to hallucinate. When a developer asks an AI tool to add a dependency and the tool suggests a non-existent package, an attacker may have already claimed that name with a malicious payload."
}
},
{
"@type": "Question",
"name": "How does Aikido Device Protection work with MDM?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Aikido Device Protection deploys through your existing MDM, meaning tools like Jamf or Kandji push the Device Protection agent to every machine in your fleet. Device Protection then handles the developer-specific attack surface that MDM cannot see, covering package registries, IDE extensions, browser plugins, and AI tool marketplaces."
}
}
]
}
]
}
</script>
