DevOps Days Amsterdamの最初の日に、Frank Breedijk氏（Schuberg Philisの security officer）がセキュリティとDevOps 間の摩擦点といかに協力してそれを避けるかについて講演した。 例としては、自動化したセキュリティテストと環境、関連するシステムコンポーネントのみにセキュリティ監査の範囲を減らすこと、あるいはセキュリティの修正は、変更のキューをジャンプして本番へ行けることができるようにすることが挙げられた。
Frankが強調したのはセキュリティと（機能提供にインセンティブが与えられる）開発部門によるセキュリティへの投資の欠如の間の摩擦、更にセキュリティと通常の仕事の上にセキュリティを不必要な負担と考える事業部からのサポートの欠如の間の摩擦だった。最後にセキュリティの人々は、しばしば、一見責任の分離の欠如と本番への変更率の増加に起因するリスクとDevOpsを見ている。Frankが提案するのは、本物のDevOps文化は開発と運用間だけでなく、彼らの両方とセキュリティ間のコラボを推進すべきである、ということだ。（Http/HttpS, Imap/ImapSのような頭字語に引っ掛けてDevOpSのSだと冗談を言った）。
すべての当事者間のコラボは、一方でセキュリティ要件を分かりやすく説明し、もう一方でシステムへの変更の可視性を高め、その結果セキュリティの脅威の恐れを減少させることによって増すことができる。例えば、PCI DSS と SOX監査に関する共通の誤解は、実際に一部のコンポーネントのみが承認を必要とするときにシステム全体を監査する必要があると考えることだ。一方、本番への変更のデリバリ率は、典型的にはDevOpsの採用で著しく増加する。ロールバックすることは、もはや選択肢なく、早めに修正することが、優先度の高いセキュリティ修正を提供する能力の増加で可能になる（変更のキューをジャンプして本番へ）。
Frankによれば、高いデリバリ率は必ずしもセキュリティにとって問題であるとは限らない。誰にでも見えるなら、より小さな変更は、セキュリテイの分析やテストを容易にする。更にデリバリの窓数が増加すると、本番におけるセキュリティ問題への迅速な修正が可能になる。最後に、動的な本番環境を管理するためのインフラ構成の管理に焦点を当てるのもまた、インフラセキュリティのテストに役立つ。例えば、新しいマシンのプロビジョニングに使用するOSイメージが必要なすべてのセキュリティパッチを含んでいるかを自動的にチェックすること。全体的には、セキュリティ環境とテストの自動化は、より簡単になっており、次にデリバリパイプラインに統合することが簡単にできるようになるだろう。
Frankはまた、機能指向のアジャイル開発チームと製品のオーナーの考え方にセキュリティ要件を含むことの難しさを指摘した。そのような要件を満たすための作業は、開発の反復で計画する必要があり、例えばセキュリティ欠陥を修正することによる技術的負債の削減は、機能を提供するのと同じぐらいに報われるべきである。
全体的に、Frankが提案するのは、真のDevOps文化は、セキュリティチームを受け入れ、誰もが機能的変更を提供することがセキュリティと運用要件を満たすことにもなるように働くように、インセンティブを揃えることである。セキュリティチームは、変更を提供するのに、ボトルネックとして見られるべきではなく、免疫系の一種として、脅威を検出し、それらを修正するために必要な洞察力やツールを提供する。
この講演は、カンファレンスの残りの部分と同様にライブストリームされた [Day1の 2:40:00 に開始] 。スライド も入手できる。