Seal Security — JavaScript (npm) の例

最小限で意図的に脆弱性を持たせたNode.js/Expressアプリケーションです。エンドツーエンドで、Seal Securityが既知のCVEをどのように修復するかを実演します。脆弱な依存関係をシールドされた（バックポートされたドロップイン）バージョンに置き換えることで、宣言したバージョン範囲やコードを変更することなく実現します。

これは、CI/CDにおけるSeal CLIのフロントからバックまでのスモークテストとして設計されています。アプリを実行し、実際のエクスプロイトをトリガーし、Sealを実行し、同じエクスプロイトがブロックされるのを確認します。

この例が示すこと

このアプリには、他にも有名な脆弱性のある依存関係（lodash 4.17.5、json5 0.5.1、got 6.7.1）が含まれており、Sealはそれぞれをシールドビルドに修復します。

エクスプロイトの仕組み

アプリはURLクエリ文字列全体をそのままEJSレンダリング呼び出しに展開します：

const data = { name: 'World', ...req.query };
res.render('page', data, ...)

また、EJSはsettings['view options']オブジェクトを受け入れ、そのoutputFunctionNameの値がサニタイズされずにコンパイルされたテンプレート関数の本体に書き込まれます。そのため、攻撃者はNode.jsプロセスの権限でサーバー上で実行される任意のJavaScriptを注入できます。

通常のリクエスト

/?name=alice

Hello alice!がレンダリングされます。

エクスプロイトリクエスト

/?name=Hacker&settings[view%20options][outputFunctionName]=x;setTimeout(function()%7Bprocess.exit(1)%7D,3000);s

サーバーはsetTimeout(function(){ process.exit(1) }, 3000)を実行します。ページは最初にロードされ、RCEが成功したことを明確に表示します。数秒後にリロードするとERR_CONNECTION_REFUSEDが表示されます — 注入されたコードがサーバーを強制終了し、任意のコードが実行されたことを証明します。

3秒の遅延は意図的です：プロセスが終了する前にレスポンスがブラウザに届くようにし、フリーズしたタブではなく「エクスプロイト成功」ページが表示されてからきれいにクラッシュするようにします。

リポジトリ構成

.
├── index.js                       # the vulnerable Express app
├── views/                         # EJS templates
├── package.json / package-lock.json
├── Jenkinsfile                    # example Jenkins (Groovy) pipeline with the Seal stage
└── .github/workflows/
    ├── build-and-run.yml          # build + expose the app for browser testing
    └── seal-security.yml          # run Seal remediation, then start the app

前提条件

SealはSaaS、Sealホステッドです — 環境内には何もインストールされず、すべてのトラフィックはアウトバウンドHTTPS（TCP 443）のみです。修復を実行するには以下が必要です：

これらはSettings → Secrets and variables → Actions（GitHub）またはManage Jenkins → Credentials（Jenkins）で設定してください。トークンをリポジトリにコミットしないでください。

アウトバウンド443に対して以下のSealホストを許可リストに追加してください：app.sealsecurity.io、authorization.sealsecurity.io、cli.sealsecurity.io、そしてシールドされたnpmパッケージ用に**npm.sealsecurity.io**。CLIバイナリはgithub.com / objects.githubusercontent.comからダウンロードされます。

ローカルで実行

npm install
npm start           # → http://localhost:3001

http://localhost:3001/?name=aliceを開く（動作）、次に上記のエクスプロイトURL（サーバーがクラッシュ）。

Sealで修復

Seal CLIは1つの追加ステップとして、npm installの後、パッケージングの前に実行されます。解決された依存関係をスキャンし、脆弱なものをシールドバージョンに書き換えます。リモート修正モードを使用します（ポリシーはSeal UIで一元管理）。

オプションA — GitHub Actions

seal-community/cli-action を使用します：

- uses: seal-community/cli-action@latest
  with:
    mode: fix
    fix_mode: remote
    token: ${{ secrets.SEAL_TOKEN }}
    target: package-lock.json     # the lock file for this ecosystem

Actions → “Seal Security Remediation” → Run workflow から実行してください。.github/workflows/seal-security.yml を参照。

オプションB — Jenkins（Groovyパイプライン）

インストール後、パッケージング前に追加する1つのステージ。Jenkinsfile を参照：

stage('Seal') {
  steps {
    sh '''
      curl -fsSL https://github.com/seal-community/cli/releases/download/latest/seal-linux-amd64-latest -o seal
      chmod +x seal
      ./seal fix --mode remote "$SEAL_MANIFEST"   # SEAL_MANIFEST=package-lock.json
    '''
  }
}

SEAL_TOKENはseal-token Jenkins認証情報から取得されます。SEAL_PROJECTをSealプロジェクトIDに設定してください。

Sealが変更するもの

seal fixの後、脆弱な依存関係はSealのレジストリからのシールドビルドに解決されます — package.jsonのバージョン範囲は変わりません：

シールドバージョンは、セキュリティ修正がバックポートされた同じパッケージであり、そのまま置き換えられます — コードの変更もメジャーバージョンアップグレードもありません。

修正の確認

修復されたアプリに対してエクスプロイトURLを再実行してください。インジェクションは実行されません：シールドされたejsは悪意のあるoutputFunctionNameを拒否し、アプリはペイロードを実行する代わりに**「Invalid parameter」**で応答します。サーバーは起動したままです。

独自のプロジェクトにSealを追加する方法

1. パイプラインに1つのステップを追加します。依存関係のインストール後、パッケージング/バンドル前に。
2. seal fixを特定のマニフェスト/ロックファイルに向けます — npmの場合はpackage-lock.json。複数のマニフェストがあるリポジトリでは、マニフェストごとに1回seal fixを実行します。
3. リモート修正モードを使用して、セキュリティチームがSeal UIで修復ポリシーを一元管理できるようにします — リポジトリにコミットされるものはありません。
4. CIシークレットストア（GitHubシークレット/Jenkins認証情報）を介してSealトークンを提供します。

これで統合は完了です — 1つのステージ、アウトバウンドのみ、アプリケーションコードの変更はありません。