製品
コード、クラウド、ランタイムのセキュリティを確保するために必要なすべてを1つの集中管理システムで実現
コード
依存関係
オープンソースのリスクを防ぐ(SCA)
機密事項
暴露された秘密をキャッチ
SAST
記述通りの安全なコード
コンテナ画像
画像を簡単に保護
マルウェア
サプライチェーン攻撃の防止
コードとしてのインフラ
IaCの設定ミスをスキャンする
ライセンス・リスクとSBOM
リスクを回避し、コンプライアンスを遵守する
時代遅れのソフトウェア
EOLランタイムを知る
クラウド
クラウド / CSPM
クラウドの設定ミス
DAST
ブラックボックス・セキュリティ・テスト
APIスキャン
APIの脆弱性をテストする
仮想マシン
代理店なし、諸経費なし
ディフェンス
ランタイム保護
アプリ内ファイアウォール / WAF
特徴
AI 自動修正機能
Aikido AIによる1クリック修正
CI/CD セキュリティ
マージおよびデプロイ前のスキャン
IDEインテグレーション
コーディング中にすぐにフィードバックを得る
オンプレミスキャナ
コンプライアンス優先のローカル・スキャン
ソリューション
使用例
コンプライアンス
SOC 2、ISO、その他の自動化
脆弱性管理
オールインワンの脆弱性管理
コード保護
高度なコード・セキュリティ
SBOMの生成
1クリック SCAレポート
ASPM
包括的なアプリケーションセキュリティ
CSPM
エンド・ツー・エンドのクラウドセキュリティ
AikidoのAI
AikidoのAIに任せる
ブロック0日
被害を受ける前に脅威を遮断する
産業別
フィンテック
ヘルステック
HRテック
リーガルテック
グループ会社
エージェンシー
スタートアップ企業
企業
モバイルアプリ
製造業
価格
リソース
開発者
資料
Aikidoの使い方
公開APIドキュメント
Aikido 開発者ハブ
変更履歴
出荷状況を見る
セキュリティ
社内リサーチ
マルウェア&CVEインテリジェンス
学ぶ
ソフトウェア・セキュリティ・アカデミー
トラストセンター
安全、プライベート、コンプライアンス
ブログ
最新記事
オープンソース
Aikido インテル
マルウェア&OSS脅威フィード
禅
アプリ内ファイアウォール保護
OpenGrep
コード解析エンジン
インテグレーション
IDE
CI/CDシステム
クラウド
Gitシステムズ
コンプライアンス
メッセンジャー
タスクマネージャー
その他の統合
について
について
について
チーム紹介
採用情報
募集中
プレスリリース
ブランドアセットのダウンロード
カレンダー
また会えますか?
オープンソース
OSSプロジェクト
お客様のフィードバック
最高のチームからの信頼
パートナープログラム
パートナー制度
お問い合わせ
ログイン
無料で始める
CC不要
Aikido
メニュー
Aikido
EN
EN
FR
JP
DE
PT
ログイン
無料で始める
CC不要
学ぶ
/
コンプライアンス・フレームワーク・ハブ
/
第1章第2章第3章

HIPAA / HITECH

6読了時間170

次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章

TL;DR

米国の医療データに触れるソフトウェアを作る?HIPAAコンプライアンスは譲れません。

セキュリティ・ルール=ePHIを暗号化し、アクセスをロックダウンし、すべてを記録する。

プライバシー・ルール=誰が何を見るかを管理する

違反通告規則=迅速に開示せよ

そして、HITECHのおかげで、あなた(ベンダー)は直接責任を負うことになります。BAAに署名し、セーフガードを厳重にしましょう。

HIPAA / HITECHスコアカードの概要:

  • 開発者の労力:アクセス制御、監査ログ、暗号化、PHI の慎重な取り扱い、医療データリスクに対する安全なコーディング、BAA 要件のサポートなど、厳密な技術的保護措置を実施する必要がある)。
  • ツールコスト:中~高(暗号化ツール、堅牢なロギング/SIEM、強力なIAM/MFA、脆弱性スキャナー、HIPAAコンプライアンスに特化したプラットフォームの可能性)。
  • 市場への影響クリティカル(PHIを扱う米国のヘルスケアソフトウェア/サービスには必須。)
  • 柔軟性:中程度(ルールは何を保護しなければならないかを定義しているが、リスク分析、規模、複雑さに基づいて、セーフガードの実施方法に柔軟性を認めている。)
  • 監査の強度:高い(HHS市民権局(OCR)による監査は、違反や苦情によって引き起こされる可能性がある。)

HIPAA / HITECHとは?

HIPAA(Health Insurance Portability and Accountability Act of 1996:医療保険の相互運用性と説明責任に関する法律)は、主に以下のことを目的とした米国の連邦法である:

  1. 労働者とその家族が転職または失業した場合の健康保険適用を保護する(ポータビリティ)。
  2. 電子医療取引とコードセットの国家標準を確立する(行政簡素化)。
  3. 保護された医療情報(PHI)として知られる、個人を特定できる医療情報のプライバシーとセキュリティを保護する。

開発者やハイテク企業にとって重要なのは、いくつかの規則を通じて実施される行政簡素化条項である:

  • HIPAAプライバシー規則:PHIがどのような場合に使用され、開示されるかについての国家基準を定める。また、個人の健康情報に対する権利(アクセス、修正など)を認める。対象事業者」(ヘルスプラン、ヘルスケアクリアリングハウス、ほとんどのヘルスケアプロバイダー)およびその「ビジネスアソシエイツ」に適用される。
  • HIPAAセキュリティ規則:対象事業体または業務関係者が作成、受領、維持、または送信する電子PHI(ePHI)の機密性、完全性、および可用性を保護するための国家基準を定める。具体的な管理上、物理上、技術上の保護措置を要求している。
  • HIPAA違反通知規則:保護されていないPHIの漏洩が発生した場合、保護対象事業体および業務提携先に通知を行うことを義務付ける。

PHIには、氏名、日付、診断、治療、医療記録番号、画像、SSNなど、健康状態、ケアの提供、ケアの支払いに関連する、特定可能なあらゆる健康情報が含まれる。(GDPRの個人データの定義については、2.7.2節を参照。)

2009年のHITECH(経済的および臨床的健康のための医療情報技術)法は、HIPAAを大幅に修正した:

  • 罰則の強化:HIPAA違反に対する罰金を引き上げ、過失に基づく段階的な罰金体系を導入。
  • ビジネスアソシエイトへの規則の適用:ビジネス・アソシエイツ(ソフトウェア・ベンダーやクラウド・プロバイダーなど、対象事業体のためにPHIを取り扱う事業者)は、HIPAAセキュリティ規則のセーフガードおよびプライバシー規則の特定の条項を遵守する直接的責任を負う。
  • 医療IT導入の促進:電子カルテ(EHR)の利用を奨励。
  • 漏洩通知の強化:PHI 漏洩の個人および HHS への通知要件を強化。

HIPAAと HITECHは共に、米国における医療情報のプライバシーとセキュリティを保護する法的根拠を形成している。

なぜ重要なのか?

HIPAA/HITECHの遵守は、米国でPHIを扱う者にとって譲れないものです:

  • これは法律です:保健社会福祉省(HHS)公民権局(OCR)により施行され、違反した場合、多額の民事罰および刑事罰が科される可能性があります。
  • ヘルスケアビジネスに必要対象事業者(病院、診療所、保険会社)は、PHIを取り扱う技術ベンダー(ビジネス・アソシエイト)に対し、HIPAAを遵守し、ビジネス・アソシエイト契約(BAA)に署名することを求めている。コンプライアンスもBAAもなければ、ビジネスも成り立ちません。
  • 患者のプライバシーの保護:患者の重要な医療情報に関する基本的権利を守る。
  • データセキュリティの確保:ePHIを侵害から保護するための具体的な保護措置が義務付けられている。
  • 巨額の罰金を回避:過失の度合いに応じて、罰金は1違反につき100ドルから、1違反カテゴリーにつき年間150万ドルまで幅がある。故意の怠慢は最も高い罰金を科される。
  • 風評被害の防止:HIPAA違反は、患者の信頼を損ない、対象事業者とビジネス・アソシエイトの双方に重大な風評被害をもたらす。
  • 医療データ交換を可能にします:電子医療情報交換に必要なセキュリティとプライバシーの基盤を提供する。

PHIに触れるソフトウェアやサービスを開発する開発者にとって、HIPAA/HITECHの遵守は、米国のヘルスケア分野への市場参入と運営の基本的な要件である。

何をどのように実施するか(技術・政策)

HIPAA/HITECH の実施には、プライバシー、セキュリティ、および侵害通知に関する規則の要件を満たすことが必要である。セキュリティに関する規則は、開発者にとって最も技術的な関連性が高く、特定の技術的セーフガード("必須 "と "対処可能 "の両方の仕様)を義務づけています:

  1. アクセスコントロール(必須&アドレス指定可能):
    • 一意のユーザーID(必須):ユーザーの行動を追跡するために一意のIDを割り当てます。
    • 緊急時のアクセス手順(必須):緊急時のPHIアクセスを確保すること。
    • 自動ログオフ(アドレス指定可能):ePHI にアクセスするワークステーションにセッションタイムアウトを導入する。
    • 暗号化と復号化(アドレス指定可能):合理的かつ適切な場合には、ePHI を暗号化する(多くの場合、静止時/転送時のデー タについては、実務上必須と考えられる)。証拠:RBAC 設定、緊急アクセス文書、自動ログオフ設定、暗号化実装の詳細。
  2. 監査統制(必須):
    • ePHIを含むシステムにおける活動を記録し、調査するためのハードウェア、ソフトウェア、または手続き上の仕組みを導入すること。ログは、誰が、いつ、何にアクセスしたかを追跡しなければならない。証拠:監査ログの構成、ログのレビュー手順。
  3. 完全性コントロール(必須&対処可能):
    • ePHIを認証する仕組み(対応可能):ePHIが不正に改ざんまたは破壊されていないことを確認するための手段(チェックサムやデジタル署名など)を導入する。証拠:完全性の検証方法。
  4. 個人または団体の認証(必須):
    • ePHI へのアクセスを求める個人または組織が、請求された本人であることを確認する手 順を導入する(パスワード、PIN、生体認証、MFA など)。証拠:認証ポリシー、MFA の実施。
  5. 送信セキュリティ(必須&アドレス指定可能):
    • 完全性コントロール(アドレス指定可能):送信されたePHIが検知されずに不正に変更されないように保護する。
    • 暗号化(アドレス指定可能):合理的かつ適切な場合には、電子ネットワーク上でePHIを送信する際に暗号化する(例えば、送信中のデータにはTLSを使用する)。証拠:証拠:ネットワークセキュリティ設定、TLS の実装、データ転送ポリシー。

技術的セーフガードのほかに、実施には以下のことが必要である:

  • リスク分析:ePHIに対する潜在的なリスクと脆弱性を正確かつ徹底的に評価すること。
  • 管理上の保護措置:方針、手順、従業員研修、セキュリティ要員の指定、緊急時対応計画、ビジネス・アソシエート契約(BAA)。
  • 物理的保護:施設のアクセス制御、ワークステーションのセキュリティ、デバイス/メディアの制御。
  • プライバシー規則の遵守:PHIの使用/開示に関するポリシーの実施、プライバシー慣行に関する通知、患者の権利要求(アクセス、修正)への対応。
  • 情報漏えいの通知:情報漏えいを検知し、リスクを評価し、必要な期間(通常 60 日)内に個人および HHS/OCR に通知する手順を有すること。

実装には、安全なコーディング、強固なインフラセキュリティ(特にクラウドを使用する場合、CSPとのBAAが必要)、包括的なロギング、強力なアクセス制御、暗号化、および広範な文書化が必要である。

避けるべき一般的な間違い

HIPAA/HITECHコンプライアンスエラーは一般的であり、コストがかかります:

  1. 不完全なリスク分析:ePHIがどこに存在し、どのような脅威に直面しているかを特定するための、組織全体にわたる徹底的なリスク分析を怠ったこと。
  2. アドレス可能な」セーフガードの無視:"アドレス指定可能 "を "オプション "と誤解すること。アドレス指定可能な仕様が実装されない場合、その決定は正当な理由とともに文書化され、合理的であれば同等の代替手段が実装されなければならない。暗号化は今日、ほとんど常に合理的であるとみなされている。
  3. 監査ログの記録/レビューの欠如:不適切なアクセスや違反を検知するために、十分なロギングを実施しなかったり、監査ログを定期的にレビューしなかったりすること。
  4. PHIの不適切な廃棄:PHI を含む紙記録や電子媒体を、シュレッダー、ワイプ、または物理的に破壊することなく廃棄すること。
  5. 弱いアクセス制御:共有ログインの使用、最小特権の導入の失敗、終了/役割変更時に速やかにアクセス権を剥奪しない。
  6. 暗号化されていないPHI:適切な暗号化を行わずにePHIを送信または保管すること(特にモバイル機器やラップトップ)。
  7. 業務提携契約(BAA)がない(または不十分):ベンダー(クラウドプロバイダー、ソフトウェアツール)の責任を概説するBAAに署名することなく、ベンダーとPHIを共有すること。
  8. 不十分な従業員研修:HIPAAポリシーやセキュリティ意識に関する定期的で文書化されたトレーニングが不足しているため、ヒューマンエラー(フィッシングなど)が発生する。
  9. 侵害通知の遅延:情報漏えい通知規則で義務付けられている60日間の期限内に情報漏えいを報告しないこと。
  10. ポリシー/手順を更新しない:セキュリティポリシー、リスク分析、 緊急時対応策を定期的に見直し、 更新しない

監査役/規制当局が質問するかもしれないこと(デベロッパー・フォーカス)

HIPAA 監査を行う HHS OCR の調査官(多くの場合、違反や苦情がきっかけとなる)は、開発に影響する技術的セーフガードを精査する:

  • (アクセス・コントロール)「許可された開発者のみがePHIを含むシステムにアクセスできることをどのように保証していますか?役割ベースのアクセス制御とレビュープロセスを教えてください。"
  • (アクセス・コントロール)"開発者が本番の ePHI にアクセスする際、(許可されている場合)どのように記録されますか?"
  • (監査統制)「アプリケーション内のePHIへのアクセスを示す監査ログを提供すること。これらのログはどのように保護され、レビューされるか。"
  • (完全性)「どのようなメカニズムがアプリケーション・データベース内のePHIの完全性を保証しますか?
  • (認証)「ユーザ(患者、医療提供者、開発者)はアプリケーションに対してどのように認証されますか?MFAは使われていますか?"
  • (伝送セキュリティ)"アプリケーション、API、ユーザー間の伝送中にePHIがどのように暗号化されるかを示す(例えば、TLSの設定)。"
  • (暗号化)「アプリケーション(データベース、バックアップ)によって保存される ePHI が、静止時にどのように暗号化されるかを示す。
  • (セキュアな開発)"ePHIを暴露する可能性のある脆弱性を防ぐために、どのようなセキュアなコーディングプラクティスとテスト(SAST/DAST)が使用されていますか?"
  • (最低限必要なもの)"アプリケーションの設計は、ユーザの役割と状況に基づいて、PHIへのアクセス/表示をどのように制限するか?"

文書化されたポリシー、手順、リスク分析、トレーニング記録、BAA、およびセーフガードが実施され、有効であることを証明する技術的証拠(ログ、設定、スキャンレポート)が要求される。

開発チームのクイックウィン

ヘルスケアアプリを開発する開発チームは、これらのHIPAAに対応したクイックウィンに集中することができる:

  1. PHIの特定と最小化アプリケーション内でPHIが流れる場所を正確にマッピングする。必要最小限のPHIのみを収集し、保管する。
  2. すべてを暗号化する:輸送時(TLS 1.2+)と静止時(データベースの暗号化、ファイルシステムの暗号化)の両方で、ePHIに強力な暗号化を導入する。独自の暗号化を行わないこと。
  3. 強力な認証とアクセス制御の実施:一意のID、強力なパスワードポリシー、MFAを使用する。最小特権の原則に基づく厳格な役割ベースのアクセス制御(RBAC)を導入する。
  4. 詳細な監査ロギングの実施:ePHIに関連するすべてのアクセス、作成、変更、および削除イベントを記録する。ログは改ざんできないようにし、一元的に保存する。
  5. 安全なコーディングの実践OWASPトップ10と特定の医療データリスクについて開発者を訓練する。SAST/SCA ツールを使用して脆弱性を発見する。
  6. HIPAA適格クラウドサービスを使用する(BAA付き):クラウドプラットフォーム(AWS、Azure、GCP)を使用する場合は、HIPAA適格と指定されたサービスのみを使用し、プロバイダーと業務提携契約(BAA)を締結する。サービスを安全に構成する。
  7. データ廃棄の計画:必要に応じて特定の患者データを安全に削除できるシステムを設計する。

これを無視すれば...(コンプライアンス違反の結果)

HIPAA/HITECH規則に違反すると、深刻な結果を招く可能性があります:

  • 民事罰(CMP): HHS OCRは、過失を反映した階層構造に基づいて罰金を課す:
    • 知らなかった場合違反1件につき100~50万ドル(同一違反の場合、年間最高25万ドル)。
    • 合理的な理由違反1件につき10~50万ドル(年間最高10万ドル)。
    • 故意の怠慢(修正済み):違反1件につき1万~5万ドル(年間最高25万ドル)。
    • 故意の怠慢(是正されていない): 違反1回につき5万ドル以上(年間最大150万ドル以上)。注:年間最高額はインフレ調整後。
  • 刑事罰: 司法省(DOJ)は、故意にPHIを不正に入手または開示した場合の刑事事件を扱う。罰則には以下が含まれる:
    • 故意に最高5万ドルの罰金、最高1年の禁固刑。
    • 偽計:最高10万ドルの罰金、最高5年の禁固刑。
    • 販売/譲渡/営利/危害目的使用の意図:最高25万ドルの罰金、最高10年の禁固刑。
  • 是正措置計画(CAP):OCRは多くの場合、罰金と並行して、組織に対して詳細な監督付きの是正措置計画の実施を要求する。
  • 風評被害:違反行為と多額の罰金は、患者の信頼と社会的認知に深刻なダメージを与える。
  • 訴訟:侵害によって損害を受けた個人は、民事訴訟を起こすことができます。
  • 事業の損失:対象事業者は、非遵守のビジネス・アソシエイツとの関係を終了する。

よくあるご質問

誰がHIPAAを遵守する必要があるのか?

対象事業体(ヘルスプラン、ヘルスケアクリアリングハウス、特定の電子取引を行うヘルスケアプロバイダ)およびそのビジネスアソシエイト(対象事業体に対して、PHIへのアクセスを伴う機能を実行またはサービスを提供する個人または事業体、例えば、ソフトウェアベンダー、クラウドプロバイダ、請求サービス、弁護士)。

PHIとePHIの違いは何ですか?

PHI(保護されるべき健康情報)とは、個人を特定できるあらゆる形態の健康情報(口頭、紙、電子的)である。ePHIとは、電子的形態で作成、受領、維持、送信されるPHIである。HIPAAセキュリティ・ルールは、特にePHIに適用される。

業務提携契約(BAA)とは?

BAAは、対象事業者とビジネス・アソシエイト(または2つのビジネス・アソシエイト)間で締結される、HIPAAが要求する書面による契約です。BAAには、セーフガードの実施や違反の報告など、HIPAA規則に従ってPHIを保護するためのBAの責任が概説されています。BAAを締結せずにPHIをベンダーと共有することは、HIPAA違反となります。

セキュリティ規則における「必須(Required)」と「対応可能(Addressable)」の仕様の違いは何ですか?

  • 必須:記載されたとおりに実施されなければならない。
  • アドレス可能:評価されなければならない。合理的かつ適切と判断された場合、実施されなければならない。そうでない場合は、その根拠を文書化し、妥当であれば同等の代替手段を実施しなければならない。対応可能とは、オプションという意味ではない。

HIPAA違反の報告期限は?

500人以上の個人に影響を及ぼす違反は、不合理な遅延なく、発見後60日以内にHHS OCRに報告されなければならない。影響を受けた個人も60日以内に通知されなければならない。500人未満に影響する情報漏えいは、記録され、毎年(暦年の終わりから60日以内に)HHS OCRに報告されなければならない。州法は、より厳しい報告期限を定めている場合がある。

HIPAA認定はありますか?

いいえ、HHS OCRは、ソフトウェア、組織、または個人に対して公式なHIPAA認証を提供または推奨していません。企業は「HIPAA準拠」を主張したり、(SOC 2 + HIPAAなどの)第三者認証/報告書を取得することがありますが、政府発行のHIPAA証明書はありません。

HITECHはHIPAAをどのように変えるのか?

HITECHは主に、罰則の強化、ビジネス・アソシエイトのコンプライアンスへの直接責任化、EHR導入の促進、違反通知ルールの強化により、HIPAAを強化した。HITECHは、実質的にHIPAAの執行をより強化するものである。

次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
次の章へ
前章
ジャンプする
テキストリンク


25k以上の組織から信頼されている。

無料で始める
CC不要
デモを予約する
シェアする

www.aikido.dev/learn/software-security-tools/hipaa-hitech

目次

第1章 コンプライアンスの枠組みを理解する

コンプライアンス・フレームワークとは何か?
コンプライアンスフレームワークがDevSecOpsワークフローに与える影響
フレームワークに共通する要素

第2章 主要なコンプライアンス・フレームワークの解説

SOC 2 コンプライアンス
ISO 27001
ISO 27017 / 27018
NIST SP 800-53
NIST SSDF (SP 800-218)
OWASP ASVS
GDPR
NIS2指令
DORA
EUサイバーレジリエンス法(CRA)
コンピュータ媒介言語
PCI DSS
FedRAMP
HIPAA / HITECH
エッセンシャル・エイト
シンガポールCCoP(CII向け)
サイバーセキュリティ法関連(APPI)

第3章 開発におけるコンプライアンスの導入

組織に適したフレームワークの選択
コンプライアンスに準拠したDevSecOpsパイプラインの構築
開発チームのコンプライアンス研修
開発者のための監査準備
長期的なコンプライアンスの維持
終わり

関連ブログ記事

すべて見る
すべて見る
2024年6月4日
-
コンプライアンス

SOC 2認証:私たちが学んだ5つのこと

監査中にSOC 2について学んだこと。ISO 27001とSOC 2の比較、タイプ2が理にかなっている理由、米国の顧客にとってSOC 2認証がいかに不可欠であるか。

2024年1月16日
-
コンプライアンス

NIS2:誰が影響を受けるのか?

NIS2は誰に適用されるのか?誰に影響するのか?必要不可欠で重要なセクターと企業規模の基準値は?AikidoアプリにはNIS2レポート機能があります。

2023年12月5日
-
コンプライアンス

ISO 27001認証:私たちが学んだ8つのこと

ISO 27001:2022準拠プロセスを開始する前に知っておきたかったこと。ISO27001認証取得を目指すSaaS企業へのヒントをご紹介します。

会社概要
製品価格について採用情報お問い合わせパートナー制度
リソース
資料公開APIドキュメント脆弱性データベースブログインテグレーション用語集プレスリリースカスタマーレビュー
セキュリティ
トラストセンターセキュリティの概要クッキー設定の変更
リーガル
プライバシーポリシークッキーポリシー利用規約マスターサブスクリプション契約データ処理契約
使用例
コンプライアンスSAST & DASTASPM脆弱性管理SBOMの生成WordPressセキュリティコード保護マイクロソフトのためのAikidoAikido ためのAikido
産業別
ヘルステックメドテックフィンテックセキュリティテックリーガルテックHRテックエージェント向け企業向けPEおよびグループ会社向け
比較する
全ベンダーとの比較vs Snyk対Wizvs Mendvs オルカ・セキュリティvs Veracodevs GitHubアドバンスドセキュリティvs GitLab Ultimatevs Checkmarxvs Semgrepvs SonarQube
リンクする
hello@aikido.dev
LinkedInX
サブスクライブ
すべての最新情報を入手
まだまだ。
👋🏻 ご登録ありがとうございます!
チーム Aikido
まだまだ。
© 2025 Aikido Security BV | BE0792914919
🇪🇺 登録住所:Coupure Rechts 88, 9000, Ghent, Belgium
🇪🇺 事務所所在地:Gebroeders van Eyckstraat 2, 9000, Ghent, Belgium
🇺🇸 事務所住所:95 Third St, 2nd Fl, San Francisco, CA 94103, US
SOC 2
コンプライアンス
ISO 27001
コンプライアンス