Advanced Security で依存関係スキャンアラートを無視する
Advanced Security の依存関係スキャンは、ソース コードで使用されているオープンソース コンポーネントを検出し、関連する脆弱性があるかどうかを識別します。 オープンソースコンポーネントから見つかった脆弱性には、アラートとしてフラグが設定されます。 この更新プログラムでは、誤検知または許容可能なリスクであると考えられる Advanced Security の依存関係スキャン アラートを無視できます。
Azure Repos では、新しいブランチを作成するときに "ポリシーの編集" アクセス許可を削除するように既定の動作を変更しました。
これらの機能の詳細については、リリース ノートを参照してください。
Azure DevOps 用の GitHub Advanced Security
Azure Boards
Azure Pipelines
- Kubernetes タスクで kubelogin がサポートされるようになりました
- YAML cron スケジュールへの更新
- チェックを無効にする
- 承認 REST API の機能強化
- クラシック パイプラインの作成を制御するための新しいトグル
Azure Repos
全般
Advanced Security で依存関係スキャン アラートのアラートを無視する
これで、誤検知または許容可能なリスクであると思われる依存関係スキャン アラートを無視できるようになりました。 これらは、現在使用できる Advanced Security のシークレット スキャンとコード スキャン アラートの場合と同じ無視オプションです。
場合によっては、依存関係スキャン タスクを使用して検出パイプラインを再実行し、これらのアラートを無視するためのアクセス許可があることを確認 Advanced Security: dismiss alerts する必要があります。
アラートの無視の詳細については、「依存関係スキャンアラートを無視する」を参照してください。
Azure Boards
作業項目へのリンクのコピー
Azure Boards の複数の領域から作業項目の URL をコピーするように少し改善しました。 特定の作業項目への直接リンクを簡単に取得できるようにします。
コピー リンク が作業項目フォーム、バックログ、タスク バックログのコンテキスト メニューに追加されました。
Note
この機能は、 New Boards Hubs プレビューでのみ使用できます。
Azure Pipelines
Kubernetes タスクで kubelogin がサポートされるようになりました
kubelogin をサポートするために、KuberentesManifest@1、HelmDeploy@0、Kubernetes@1、およびAzureFunctionOnKubernetes@1タスクを更新しました。 これにより、Azure Active Directory 統合で構成された Azure Kubernetes Service (AKS) をターゲットにできます。
Kubelogin は、ホストされているイメージにプレインストールされていません。 上記のメンションタスクで kubelogin が使用されていることを確認するには、それに依存するタスクの前にKubeloginInstaller@0 タスクを挿入してインストールします。
- task: KubeloginInstaller@0
- task: HelmDeploy@0
# arguments do not need to be modified to use kubelogin
承認 REST API の機能強化
承認運用環境へのデプロイを手動で確認できるようにすることで、YAML パイプラインのセキュリティを強化できます。 承認クエリ REST API を更新して、より強力にしました。 次の手順を実行します。
- リスト
approvalIdを指定する必要はありません。 すべてのパラメーターが省略可能になりました。 - s の
userIdリストを指定して、これらのユーザーに対して保留中の承認の一覧を取得できます。 現在、REST API は、ユーザーが承認者として明示的に割り当てられている承認の一覧を返します。 - たとえば
pending、返される承認を指定stateできます。
例を次に示します。 GET https://dev.azure.com/fabrikamfiber/fabrikam-chat/_apis/pipelines/approvals?api-version=7.1-preview.1&userId=47acd774-9773-6c31-bbb6-5a0585695d19&state=pending
{
"count": 2,
"value":
[
{
"id": "87436c03-69a3-42c7-b5c2-6abfe049ee4c",
"steps": [],
"status": "pending",
"createdOn": "2023-06-27T13:58:07.417Z",
"lastModifiedOn": "2023-06-27T13:58:07.4164237Z",
"executionOrder": "anyOrder",
"minRequiredApprovers": 1,
"blockedApprovers": [],
"_links":
{
"self":
{
"href": "https://dev.azure.com/fabrikamfiber/fabricam-chat/_apis/pipelines/approvals/87436c03-69a3-42c7-b5c2-6abfe049ee4c"
}
}
},
{
"id": "2549baca-104c-4a6f-b05f-bdc4065a53b7",
"steps": [],
"status": "pending",
"createdOn": "2023-06-27T13:58:07.417Z",
"lastModifiedOn": "2023-06-27T13:58:07.4164237Z",
"executionOrder": "anyOrder",
"minRequiredApprovers": 1,
"blockedApprovers": [],
"_links":
{
"self":
{
"href": "https://dev.azure.com/fabrikamfiber/fabricam-chat/_apis/pipelines/approvals/2549baca-104c-4a6f-b05f-bdc4065a53b7"
}
}
}
]
}
チェックを無効にする
デバッグチェックを少なくしました。 Azure 関数の呼び出しまたは REST API の呼び出しチェックが正しく機能せず、修正が必要な場合があります。 以前は、このようなチェックを削除して、デプロイを誤ってブロックしないようにする必要がありました。 チェックを修正したら、それを再度追加して正しく構成し、必要なすべてのヘッダーが設定されているか、クエリ パラメーターが正しいことを確認する必要がありました。 これは面倒です。
これで、チェックを無効にできます。 無効になっているチェックは、後続のチェック スイートの評価では実行されません。
誤ったチェックを修正したら、それを有効にすることができます。
YAML cron スケジュールへの更新
YAML パイプラインでは、YAML プロパティを使用してスケジュールされたトリガーをcron定義できます。
batch プロパティの動作を更新しました。 簡単に言うと、batch を true に設定した場合、別のスケジュールされたパイプラインの実行が進行中の場合、cron スケジュールは実行されません。 これは、パイプライン リポジトリのバージョンに関係なく行われます。
always と batch の相互作用についての説明を以下の表に示します。
| 常時 | Batch | Behavior |
|---|---|---|
false |
false |
最後に成功したスケジュールされたパイプライン実行に関する変更がある場合にのみ、パイプラインが実行されます |
false |
true |
パイプラインの実行は、最後に成功したスケジュールされたパイプラインの実行に関する変更があり、進行中のスケジュールされたパイプラインの実行がない場合にのみ実行されます |
true |
false |
cron スケジュールに従ってパイプラインを実行する |
true |
true |
cron スケジュールに従ってパイプラインを実行する |
たとえば、.always: false.batch: true パイプラインを 5 分ごとに実行する必要があることを指定する cron スケジュールがあるとします。 新しいコミットがあるとします。 5 分以内に、パイプラインはスケジュールされた実行を開始します。 パイプラインの実行が完了するまでに 30 分かかるとします。 この 30 分以内に、コミットの数に関係なく、スケジュールされた実行は行われません。 次のスケジュールされた実行は、現在のスケジュールされた実行が完了した後にのみ行われます。
YAML パイプラインには複数の cron スケジュールが含まれている場合があり、どの cron スケジュールを実行するかに基づいて、パイプラインで異なるステージ/ジョブを実行できます。 たとえば、夜間ビルドと毎週のビルドがあり、毎週のビルド中にパイプラインでさらに統計情報を収集する必要があるとします。
これを可能にするには、cron スケジュールのプロパティを含むdisplayName名前Build.CronSchedule.DisplayNameの新しい定義済みシステム変数を導入します。
クラシック パイプラインの作成を制御するための新しいトグル
昨年、クラシック ビルドとリリース パイプラインの作成を無効にする Pipelines 構成設定を開始しました。
フィードバックに応じて、最初の切り替えが 2 つに分割されました。1 つはクラシック ビルド パイプライン用、1 つはクラシック リリース パイプライン、デプロイ グループ、タスク グループ用です。
組織でトグルが Disable creation of classic build and release pipelines オンになっている場合は、両方の新しいトグルがオンになります。 元のトグルがオフの場合、両方の新しいトグルがオフになります。
Azure Repos
ブランチ作成者に対する "ポリシーの編集" アクセス許可の削除
以前は、新しいブランチを作成したときに、そのブランチのポリシーを編集するアクセス許可が付与されています。 この更新プログラムでは、リポジトリに対して "アクセス許可の管理" 設定がオンになっている場合でも、このアクセス許可を付与しないように既定の動作を変更しています。
セキュリティ アクセス許可の継承またはグループ メンバーシップによって明示的に (手動または REST API を使用して) 付与された "ポリシーの編集" アクセス許可が必要です。
次のステップ
Note
これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。
Azure DevOps に向かい、見てみましょう。
フィードバックの提供方法
これらの機能に関するご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。
Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。
よろしくお願いします。
シルヴィウ アンドリカ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示