OSS – その意味は？ OSSライセンスとは… ソフトウェアの自由な使用、改変、共有を可能にすることです。 ソフトウェアを保護し、オープンソースを維持することを目的としています。 なぜ考慮しなければならないのか？ 簡潔にお話ししましょう！ライセンスなしで運用していませんか？使用しているオープンソースソフトウェアやライセンスを見直さなかった場合、どのようなリスクがあるのでしょうか？ もしかすると、あなた自身、あなたのコード、そしてあなたの組織を以下のような危険にさらすことになるかもしれません。 特許 トレードシークレット 競争優位性 パーミッシブライセンスとコピーレフトライセンス ライセンスには2つのカテゴリーがあります。 1. パーミッシブおよびリベラル（非常にシンプル） コードを好きなように扱える 自身の責任で使用できる 作者を引用する必要がある 2. …
重要なポイント ソフトウェア部品表（SBOM）は、アプリケーションで使用されるオープンソースおよびサードパーティのソフトウェアパッケージをすべてリストアップします。 これは、サードパーティ製ソフトウェアのセキュリティ、ライセンスコンプライアンス、およびその他のリスクを監視および評価するために使用することができます。 SBOMには複数の形式があり、最も一般的なのはCycloneDXとSPDXです。 SBOMはプログラムで生成し、ソフトウェアのビルドプロセスに組み込むことができます。 そもそもSBOMとは何か？ 現代のソフトウェアは、より速く革新し、プロジェクトのユニークな側面に焦点を当てるために、オープンソースパッケージを使用して組み立てられています。ソフトウェア開発プロセスは、オープンソースコンポーネントが部品や原材料として機能し、新しい製品に組み立てられるという、従来の製造プロセスに酷似しているのです。 従来の製造業における部品表（BOM）は、最終製品を構成するすべての原材料、製造部品、数量のリストです。製造や流通のあらゆる段階で、欠陥や不良のある部品を素早く特定できるため、コンプライアンス、リスク管理、製品の安全性確保に有効です。 ソフトウェア部品表（SBOM）とは、アプリケーションに含まれるすべてのパッケージとライブラリのリストを指します。これは、デジタル版の製造業の部品表のようなものです。部品表がすべてのサブアセンブリを含むように、SBOMは推移的依存関係またはコンポーネントの依存関係も含みます。そして、従来の部品表と同様に、SBOMは、危険なパッケージがアプリケーションに含まれているかどうかを簡単に確認することができます。 ソフトウェア部品表は、プロジェクトの依存関係を管理し、オープンソースコンポーネントのリスクを管理するための最初のステップとなります。近年、オープンソースコンポーネントを標的としたサイバー攻撃が急増しており、ソフトウェアのサプライチェーンへの攻撃は2021年だけで300%も増加しています。SBOMは、依存関係を把握し、脆弱性、ライセンス問題、その他のリスクのあるコンポーネントを探すために使用することができます。ベンダーによっては、自社のセキュリティ管理のために、ソフトウェア購入時にSBOMを要求するところもあります。米国電気通信情報局は、ソフトウェア部品表に関するガイドラインを共同で発表し、将来的にベンダーにSBOMを要求するための土台を築きました。これらの規格は、その使用に関する情報を含むSBOMの最低要件を概説しています。最低要件は以下の通りです。 データフィールド – 必須のデータフィールドは、コンポーネントの識別のための一般的な情報を提供し、サプライヤ名、コンポーネント名、バージョン、依存関係、SBOMの作成者、およびデータがSBOMに追加された時間を含んでいます。 自動化サポート – SBOMは、自動的に生成し、解析するためのサポートを含まなければなりません。自動化をサポートする目的は、組織間の相互運用性です。ある組織からのSBOMは、新しいツールを採用する必要なしに、簡単に解析できるべきです。現在、SPDX、CycloneDX、ソフトウェア識別タグがこの自動化サポートに対応したフォーマットとして受け入れられています。 実践とプロセス – このセクションでは、ソフトウェア部品表を使用するための要件を概説し、頻度、深さ、アクセス、および既知の不明点の文書化に関するガイダンスを提供します。…
重要なポイント ソフトウェア開発は、従来のサプライチェーンによく似ています。 オープンソースのパッケージは、サブアセンブリや構成部品として機能します。 これらは、コンポーネントの倉庫や保管場所として機能するパッケージレジストリやホスト型アーティファクトリポジトリに格納されています。 開発チームは、これらのパーツを組み立てて、ソフトウェアアプリケーションやサービスという形で完成品に仕上げます。 これらの製品は、継続的インテグレーションシステムとウェブホスティング製品のホスティングサービスを使用して、お客様に「出荷」されます。 概要 Sonatypeのお客様、あるいはSonatypeのソリューションを検討されている方は、「ソフトウェアサプライチェーン」と「サプライチェーンマネジメント」という言葉を耳にしたことがあるのではないでしょうか。この記事では、この2つの用語の定義と比較を行い、従来のサプライチェーンがソフトウェアサプライチェーンにどのように変換されるのか、その概要を説明します。 サプライチェーンマネジメントとは？ 「サプライチェーンマネジメント」とは、未加工の原材料が完成品に加工され、消費者に届けられるまでの流れを管理することです。サプライチェーンマネジメントは、大規模なもの（原材料が海を渡るようなもの）から小規模なもの（部品がベルトコンベアーから次のベルトへと移動するようなもの）まで存在し、主に材料の移動に関係しています。 サプライチェーンマネジメントという考え方は新しいものではありません。「ローマは一日にして成らず」という言葉があるように、ローマはコンクリートの安定供給なくして建設されなかったのです。 しかし、現代のサプライチェーンマネジメントのコンセプトが確立されたのは、1980年代のことです。グローバル化は、より迅速な製造、より高い効率性、より高い品質の製品を約束した一方で、同時に深刻なリスクももたらしました。サプライチェーンマネジメントは、その利点を生かし、リスクを回避するために開発されたのです。 動きと流れ 前述したように、サプライチェーンマネジメントの主な対象は「モノの動き」です。なぜなら、品質とスピードの向上のほとんどは、材料が生産のある段階から次の段階へと移動する方法を改善することにあるからです。品質やスピードの低下は、通常、同じ原因から生じています。 動きと流れの重要性を理解するために、専門家が製造工場の効率化を任された場合の質問をいくつか考えてみましょう。この場合、材料がどこに保管されているか、どのように工場に到着するか、配送業者の信頼性はどうか、などを知りたいと思うでしょう。ベルトコンベアーの速度や、組み立て機械の能力も知りたいかもしれません。さらに、完成した製品がどれだけ速くトラックに積み込まれるか、トラックがどれだけ速く配達を完了するか、といったことも尋ねるでしょう。 ソフトウェアサプライチェーンとは？ ソフトウェアサプライチェーンとは、コンポーネント（あらかじめ作られた小さなコードの断片）が開発プロセスを経て、完成したソフトウェアになり、顧客に配布される仕組みのことです。これは、物理的な原材料が完成品に変換され、店の棚に出荷される方法に似ています。 「ソフトウェアサプライチェーン」という言葉は比較的新しく、SDLCにおけるオープンソースコンポーネントの役割に対する認識が高まった結果、2014年頃に作られた造語です。Sonatypeは、この言葉を「ソフトウェアサプライチェーンマネジメント」とともに、いち早く取り入れた企業の1つです。 …
重要なポイント DevSecOpsは、DevOpsの拡張であり、セキュリティの懸念を開発プロセスの早い段階に移すことに重点を置いています。 「シフトレフト」とは、セキュリティを考慮し、開発プロセスを前倒しして実施するという概念です。 DevSecOpsは、セキュリティへの配慮を開発の最後まで残しておくことで生じる摩擦や手戻りを減らすことを目指しています。 DevSecOpsは、開発、運用、およびセキュリティがビジネスゴールに沿って連携し、より効率的なイノベーションを実現するための画期的な手段です。 DevSecOpsは、作業原則の集合体です。ソフトウェアコンポジション解析や、安全なコンポーネント管理に関連しており、1つのツールや手順というよりも、組織が連携する手段に関するものです。 一言で言うと？ Dev.Sec.Ops. 上記の言葉を聞いたことがありますか？そうでない場合、あなただけではありません。DevSecOpsの基本的な前提は、話す相手によって異なる名前で呼ばれていることもあります（Rugged DevOps、SecDevOpsなど）。 では、DevSecOpsとは一体どういう意味なのでしょうか？まず知っておかなければならないのは、DevSecOpsの「sec」はセキュリティを意味するということでしょう。 多くの企業にとって、DevOpsの考え方を導入することは、ソフトウェア開発チームとIT運用チームの間の「ギャップを埋める」、つまり「サイロ化を防ぐ」ことであり、多くの場合、より速く、より安定したソフトウェアをリリースできるようになることを目的としています。 DevSecOps は、DevOps の概念を拡張したものであり、ソフトウェア開発ライフサイクル（SDLC）の中で「セキュリティを（つまり、より早い時期に）シフトレフトする」というキャッチフレーズで紹介されることがよくあります。セキュリティレビューや検査は、緩和措置が必要な発見があった場合、実施するのがより困難でコストがかかるサイクルの終盤に取り組むよりも、より効率的に実施することができるのです。 実際、DevSecOpsの背後にある原則、すなわち品質をソースに近づけ続けることは、「The DevOpsハンドブック」で述べられているように「DevOpsの第二の道（フィードバック）」の重要な信条でもあります。 “複雑なシステムでは、検査プロセスや承認プロセスを増やすと、かえって将来の不具合の可能性が高まります。意思決定を作業現場から遠ざけると、承認プロセスの有効性が低下します。そうすると、意思決定の質が下がるだけでなく、サイクルタイムが長くなるので、原因と結果のフィードバックの強度が低下し、成功と失敗から学ぶ能力が低下するのです。” Edwards Demingは、エンジニア、統計学教授、経営コンサルタントであり、米国で「総合品質管理（TQM)」を立ち上げるきっかけとなったことでよく知られていますが、同じ考えを（ずっと以前に）「ビジネスの有効性を変革するための（14の）主要経営原則」の3番目に提唱しています。…
今年の10 月6 日〜7 日まで、シンガポールでSonatype Partner サミットを開催されました。様々な国で活躍する有識者と弊社の代表を同席し、「日本の市場及びアジア市場を広がる戦略」とテーマした大変興味深い講演を聞きました。 Sonatype Partner Summit 2022 今回のイベントを通して、さまざまな技術のノウハウを共有しながら、世界の境を跨ぐ取組みに関心を通し、Sonatype 社はDevSamurai とのパートナーシップが強化され、日本の市場連携について披露させていただきました。 DevSamurai_Sonatype employees Nexus 関連製品 Nexus リポジトリプロ …
This website stores cookies on your computer. These cookies are used to collect information about how you interact with our website and allow us to remember you. We use this information in order to improve and customize your browsing experience and for analytics and metrics about our visitors both on this website and other media. To find out more about the cookies we use, see our Privacy Policy.
Ok 
