{
  "metadata": {
    "licenses": [
      {
        "license": {
          "id": "CC-BY-SA-3.0",
          "text": {
            "contentType": "text/plain",
            "encoding": "base64",
            "content": "Q3JlYXRpdmUgQ29tbW9ucyBMZWdhbCBDb2RlCgpBdHRyaWJ1dGlvbi1TaGFyZUFsaWtlIDMuMCBVbnBvcnRlZAoKICAgIENSRUFUSVZFIENPTU1PTlMgQ09SUE9SQVRJT04gSVMgTk9UIEEgTEFXIEZJUk0gQU5EIERPRVMgTk9UIFBST1ZJREUKICAgIExFR0FMIFNFUlZJQ0VTLiBESVNUUklCVVRJT04gT0YgVEhJUyBMSUNFTlNFIERPRVMgTk9UIENSRUFURSBBTgogICAgQVRUT1JORVktQ0xJRU5UIFJFTEFUSU9OU0hJUC4gQ1JFQVRJVkUgQ09NTU9OUyBQUk9WSURFUyBUSElTCiAgICBJTkZPUk1BVElPTiBPTiBBTiAiQVMtSVMiIEJBU0lTLiBDUkVBVElWRSBDT01NT05TIE1BS0VTIE5PIFdBUlJBTlRJRVMKICAgIFJFR0FSRElORyBUSEUgSU5GT1JNQVRJT04gUFJPVklERUQsIEFORCBESVNDTEFJTVMgTElBQklMSVRZIEZPUgogICAgREFNQUdFUyBSRVNVTFRJTkcgRlJPTSBJVFMgVVNFLgoKTGljZW5zZQoKVEhFIFdPUksgKEFTIERFRklORUQgQkVMT1cpIElTIFBST1ZJREVEIFVOREVSIFRIRSBURVJNUyBPRiBUSElTIENSRUFUSVZFCkNPTU1PTlMgUFVCTElDIExJQ0VOU0UgKCJDQ1BMIiBPUiAiTElDRU5TRSIpLiBUSEUgV09SSyBJUyBQUk9URUNURUQgQlkKQ09QWVJJR0hUIEFORC9PUiBPVEhFUiBBUFBMSUNBQkxFIExBVy4gQU5ZIFVTRSBPRiBUSEUgV09SSyBPVEhFUiBUSEFOIEFTCkFVVEhPUklaRUQgVU5ERVIgVEhJUyBMSUNFTlNFIE9SIENPUFlSSUdIVCBMQVcgSVMgUFJPSElCSVRFRC4KCkJZIEVYRVJDSVNJTkcgQU5ZIFJJR0hUUyBUTyBUSEUgV09SSyBQUk9WSURFRCBIRVJFLCBZT1UgQUNDRVBUIEFORCBBR1JFRQpUTyBCRSBCT1VORCBCWSBUSEUgVEVSTVMgT0YgVEhJUyBMSUNFTlNFLiBUTyBUSEUgRVhURU5UIFRISVMgTElDRU5TRSBNQVkKQkUgQ09OU0lERVJFRCBUTyBCRSBBIENPTlRSQUNULCBUSEUgTElDRU5TT1IgR1JBTlRTIFlPVSBUSEUgUklHSFRTCkNPTlRBSU5FRCBIRVJFIElOIENPTlNJREVSQVRJT04gT0YgWU9VUiBBQ0NFUFRBTkNFIE9GIFNVQ0ggVEVSTVMgQU5ECkNPTkRJVElPTlMuCgoxLiBEZWZpbml0aW9ucwoKIGEuICJBZGFwdGF0aW9uIiBtZWFucyBhIHdvcmsgYmFzZWQgdXBvbiB0aGUgV29yaywgb3IgdXBvbiB0aGUgV29yayBhbmQKICAgIG90aGVyIHByZS1leGlzdGluZyB3b3Jrcywgc3VjaCBhcyBhIHRyYW5zbGF0aW9uLCBhZGFwdGF0aW9uLAogICAgZGVyaXZhdGl2ZSB3b3JrLCBhcnJhbmdlbWVudCBvZiBtdXNpYyBvciBvdGhlciBhbHRlcmF0aW9ucyBvZiBhCiAgICBsaXRlcmFyeSBvciBhcnRpc3RpYyB3b3JrLCBvciBwaG9ub2dyYW0gb3IgcGVyZm9ybWFuY2UgYW5kIGluY2x1ZGVzCiAgICBjaW5lbWF0b2dyYXBoaWMgYWRhcHRhdGlvbnMgb3IgYW55IG90aGVyIGZvcm0gaW4gd2hpY2ggdGhlIFdvcmsgbWF5IGJlCiAgICByZWNhc3QsIHRyYW5zZm9ybWVkLCBvciBhZGFwdGVkIGluY2x1ZGluZyBpbiBhbnkgZm9ybSByZWNvZ25pemFibHkKICAgIGRlcml2ZWQgZnJvbSB0aGUgb3JpZ2luYWwsIGV4Y2VwdCB0aGF0IGEgd29yayB0aGF0IGNvbnN0aXR1dGVzIGEKICAgIENvbGxlY3Rpb24gd2lsbCBub3QgYmUgY29uc2lkZXJlZCBhbiBBZGFwdGF0aW9uIGZvciB0aGUgcHVycG9zZSBvZgogICAgdGhpcyBMaWNlbnNlLiBGb3IgdGhlIGF2b2lkYW5jZSBvZiBkb3VidCwgd2hlcmUgdGhlIFdvcmsgaXMgYSBtdXNpY2FsCiAgICB3b3JrLCBwZXJmb3JtYW5jZSBvciBwaG9ub2dyYW0sIHRoZSBzeW5jaHJvbml6YXRpb24gb2YgdGhlIFdvcmsgaW4KICAgIHRpbWVkLXJlbGF0aW9uIHdpdGggYSBtb3ZpbmcgaW1hZ2UgKCJzeW5jaGluZyIpIHdpbGwgYmUgY29uc2lkZXJlZCBhbgogICAgQWRhcHRhdGlvbiBmb3IgdGhlIHB1cnBvc2Ugb2YgdGhpcyBMaWNlbnNlLgogYi4gIkNvbGxlY3Rpb24iIG1lYW5zIGEgY29sbGVjdGlvbiBvZiBsaXRlcmFyeSBvciBhcnRpc3RpYyB3b3Jrcywgc3VjaCBhcwogICAgZW5jeWNsb3BlZGlhcyBhbmQgYW50aG9sb2dpZXMsIG9yIHBlcmZvcm1hbmNlcywgcGhvbm9ncmFtcyBvcgogICAgYnJvYWRjYXN0cywgb3Igb3RoZXIgd29ya3Mgb3Igc3ViamVjdCBtYXR0ZXIgb3RoZXIgdGhhbiB3b3JrcyBsaXN0ZWQKICAgIGluIFNlY3Rpb24gMShmKSBiZWxvdywgd2hpY2gsIGJ5IHJlYXNvbiBvZiB0aGUgc2VsZWN0aW9uIGFuZAogICAgYXJyYW5nZW1lbnQgb2YgdGhlaXIgY29udGVudHMsIGNvbnN0aXR1dGUgaW50ZWxsZWN0dWFsIGNyZWF0aW9ucywgaW4KICAgIHdoaWNoIHRoZSBXb3JrIGlzIGluY2x1ZGVkIGluIGl0cyBlbnRpcmV0eSBpbiB1bm1vZGlmaWVkIGZvcm0gYWxvbmcKICAgIHdpdGggb25lIG9yIG1vcmUgb3RoZXIgY29udHJpYnV0aW9ucywgZWFjaCBjb25zdGl0dXRpbmcgc2VwYXJhdGUgYW5kCiAgICBpbmRlcGVuZGVudCB3b3JrcyBpbiB0aGVtc2VsdmVzLCB3aGljaCB0b2dldGhlciBhcmUgYXNzZW1ibGVkIGludG8gYQogICAgY29sbGVjdGl2ZSB3aG9sZS4gQSB3b3JrIHRoYXQgY29uc3RpdHV0ZXMgYSBDb2xsZWN0aW9uIHdpbGwgbm90IGJlCiAgICBjb25zaWRlcmVkIGFuIEFkYXB0YXRpb24gKGFzIGRlZmluZWQgYmVsb3cpIGZvciB0aGUgcHVycG9zZXMgb2YgdGhpcwogICAgTGljZW5zZS4KIGMuICJDcmVhdGl2ZSBDb21tb25zIENvbXBhdGlibGUgTGljZW5zZSIgbWVhbnMgYSBsaWNlbnNlIHRoYXQgaXMgbGlzdGVkCiAgICBhdCBodHRwczovL2NyZWF0aXZlY29tbW9ucy5vcmcvY29tcGF0aWJsZWxpY2Vuc2VzIHRoYXQgaGFzIGJlZW4KICAgIGFwcHJvdmVkIGJ5IENyZWF0aXZlIENvbW1vbnMgYXMgYmVpbmcgZXNzZW50aWFsbHkgZXF1aXZhbGVudCB0byB0aGlzCiAgICBMaWNlbnNlLCBpbmNsdWRpbmcsIGF0IGEgbWluaW11bSwgYmVjYXVzZSB0aGF0IGxpY2Vuc2U6IChpKSBjb250YWlucwogICAgdGVybXMgdGhhdCBoYXZlIHRoZSBzYW1lIHB1cnBvc2UsIG1lYW5pbmcgYW5kIGVmZmVjdCBhcyB0aGUgTGljZW5zZQogICAgRWxlbWVudHMgb2YgdGhpcyBMaWNlbnNlOyBhbmQsIChpaSkgZXhwbGljaXRseSBwZXJtaXRzIHRoZSByZWxpY2Vuc2luZwogICAgb2YgYWRhcHRhdGlvbnMgb2Ygd29ya3MgbWFkZSBhdmFpbGFibGUgdW5kZXIgdGhhdCBsaWNlbnNlIHVuZGVyIHRoaXMKICAgIExpY2Vuc2Ugb3IgYSBDcmVhdGl2ZSBDb21tb25zIGp1cmlzZGljdGlvbiBsaWNlbnNlIHdpdGggdGhlIHNhbWUKICAgIExpY2Vuc2UgRWxlbWVudHMgYXMgdGhpcyBMaWNlbnNlLgogZC4gIkRpc3RyaWJ1dGUiIG1lYW5zIHRvIG1ha2UgYXZhaWxhYmxlIHRvIHRoZSBwdWJsaWMgdGhlIG9yaWdpbmFsIGFuZAogICAgY29waWVzIG9mIHRoZSBXb3JrIG9yIEFkYXB0YXRpb24sIGFzIGFwcHJvcHJpYXRlLCB0aHJvdWdoIHNhbGUgb3IKICAgIG90aGVyIHRyYW5zZmVyIG9mIG93bmVyc2hpcC4KIGUuICJMaWNlbnNlIEVsZW1lbnRzIiBtZWFucyB0aGUgZm9sbG93aW5nIGhpZ2gtbGV2ZWwgbGljZW5zZSBhdHRyaWJ1dGVzCiAgICBhcyBzZWxlY3RlZCBieSBMaWNlbnNvciBhbmQgaW5kaWNhdGVkIGluIHRoZSB0aXRsZSBvZiB0aGlzIExpY2Vuc2U6CiAgICBBdHRyaWJ1dGlvbiwgU2hhcmVBbGlrZS4KIGYuICJMaWNlbnNvciIgbWVhbnMgdGhlIGluZGl2aWR1YWwsIGluZGl2aWR1YWxzLCBlbnRpdHkgb3IgZW50aXRpZXMgdGhhdAogICAgb2ZmZXIocykgdGhlIFdvcmsgdW5kZXIgdGhlIHRlcm1zIG9mIHRoaXMgTGljZW5zZS4KIGcuICJPcmlnaW5hbCBBdXRob3IiIG1lYW5zLCBpbiB0aGUgY2FzZSBvZiBhIGxpdGVyYXJ5IG9yIGFydGlzdGljIHdvcmssCiAgICB0aGUgaW5kaXZpZHVhbCwgaW5kaXZpZHVhbHMsIGVudGl0eSBvciBlbnRpdGllcyB3aG8gY3JlYXRlZCB0aGUgV29yawogICAgb3IgaWYgbm8gaW5kaXZpZHVhbCBvciBlbnRpdHkgY2FuIGJlIGlkZW50aWZpZWQsIHRoZSBwdWJsaXNoZXI7IGFuZCBpbgogICAgYWRkaXRpb24gKGkpIGluIHRoZSBjYXNlIG9mIGEgcGVyZm9ybWFuY2UgdGhlIGFjdG9ycywgc2luZ2VycywKICAgIG11c2ljaWFucywgZGFuY2VycywgYW5kIG90aGVyIHBlcnNvbnMgd2hvIGFjdCwgc2luZywgZGVsaXZlciwgZGVjbGFpbSwKICAgIHBsYXkgaW4sIGludGVycHJldCBvciBvdGhlcndpc2UgcGVyZm9ybSBsaXRlcmFyeSBvciBhcnRpc3RpYyB3b3JrcyBvcgogICAgZXhwcmVzc2lvbnMgb2YgZm9sa2xvcmU7IChpaSkgaW4gdGhlIGNhc2Ugb2YgYSBwaG9ub2dyYW0gdGhlIHByb2R1Y2VyCiAgICBiZWluZyB0aGUgcGVyc29uIG9yIGxlZ2FsIGVudGl0eSB3aG8gZmlyc3QgZml4ZXMgdGhlIHNvdW5kcyBvZiBhCiAgICBwZXJmb3JtYW5jZSBvciBvdGhlciBzb3VuZHM7IGFuZCwgKGlpaSkgaW4gdGhlIGNhc2Ugb2YgYnJvYWRjYXN0cywgdGhlCiAgICBvcmdhbml6YXRpb24gdGhhdCB0cmFuc21pdHMgdGhlIGJyb2FkY2FzdC4KIGguICJXb3JrIiBtZWFucyB0aGUgbGl0ZXJhcnkgYW5kL29yIGFydGlzdGljIHdvcmsgb2ZmZXJlZCB1bmRlciB0aGUgdGVybXMKICAgIG9mIHRoaXMgTGljZW5zZSBpbmNsdWRpbmcgd2l0aG91dCBsaW1pdGF0aW9uIGFueSBwcm9kdWN0aW9uIGluIHRoZQogICAgbGl0ZXJhcnksIHNjaWVudGlmaWMgYW5kIGFydGlzdGljIGRvbWFpbiwgd2hhdGV2ZXIgbWF5IGJlIHRoZSBtb2RlIG9yCiAgICBmb3JtIG9mIGl0cyBleHByZXNzaW9uIGluY2x1ZGluZyBkaWdpdGFsIGZvcm0sIHN1Y2ggYXMgYSBib29rLAogICAgcGFtcGhsZXQgYW5kIG90aGVyIHdyaXRpbmc7IGEgbGVjdHVyZSwgYWRkcmVzcywgc2VybW9uIG9yIG90aGVyIHdvcmsKICAgIG9mIHRoZSBzYW1lIG5hdHVyZTsgYSBkcmFtYXRpYyBvciBkcmFtYXRpY28tbXVzaWNhbCB3b3JrOyBhCiAgICBjaG9yZW9ncmFwaGljIHdvcmsgb3IgZW50ZXJ0YWlubWVudCBpbiBkdW1iIHNob3c7IGEgbXVzaWNhbAogICAgY29tcG9zaXRpb24gd2l0aCBvciB3aXRob3V0IHdvcmRzOyBhIGNpbmVtYXRvZ3JhcGhpYyB3b3JrIHRvIHdoaWNoIGFyZQogICAgYXNzaW1pbGF0ZWQgd29ya3MgZXhwcmVzc2VkIGJ5IGEgcHJvY2VzcyBhbmFsb2dvdXMgdG8gY2luZW1hdG9ncmFwaHk7CiAgICBhIHdvcmsgb2YgZHJhd2luZywgcGFpbnRpbmcsIGFyY2hpdGVjdHVyZSwgc2N1bHB0dXJlLCBlbmdyYXZpbmcgb3IKICAgIGxpdGhvZ3JhcGh5OyBhIHBob3RvZ3JhcGhpYyB3b3JrIHRvIHdoaWNoIGFyZSBhc3NpbWlsYXRlZCB3b3JrcwogICAgZXhwcmVzc2VkIGJ5IGEgcHJvY2VzcyBhbmFsb2dvdXMgdG8gcGhvdG9ncmFwaHk7IGEgd29yayBvZiBhcHBsaWVkCiAgICBhcnQ7IGFuIGlsbHVzdHJhdGlvbiwgbWFwLCBwbGFuLCBza2V0Y2ggb3IgdGhyZWUtZGltZW5zaW9uYWwgd29yawogICAgcmVsYXRpdmUgdG8gZ2VvZ3JhcGh5LCB0b3BvZ3JhcGh5LCBhcmNoaXRlY3R1cmUgb3Igc2NpZW5jZTsgYQogICAgcGVyZm9ybWFuY2U7IGEgYnJvYWRjYXN0OyBhIHBob25vZ3JhbTsgYSBjb21waWxhdGlvbiBvZiBkYXRhIHRvIHRoZQogICAgZXh0ZW50IGl0IGlzIHByb3RlY3RlZCBhcyBhIGNvcHlyaWdodGFibGUgd29yazsgb3IgYSB3b3JrIHBlcmZvcm1lZCBieQogICAgYSB2YXJpZXR5IG9yIGNpcmN1cyBwZXJmb3JtZXIgdG8gdGhlIGV4dGVudCBpdCBpcyBub3Qgb3RoZXJ3aXNlCiAgICBjb25zaWRlcmVkIGEgbGl0ZXJhcnkgb3IgYXJ0aXN0aWMgd29yay4KIGkuICJZb3UiIG1lYW5zIGFuIGluZGl2aWR1YWwgb3IgZW50aXR5IGV4ZXJjaXNpbmcgcmlnaHRzIHVuZGVyIHRoaXMKICAgIExpY2Vuc2Ugd2hvIGhhcyBub3QgcHJldmlvdXNseSB2aW9sYXRlZCB0aGUgdGVybXMgb2YgdGhpcyBMaWNlbnNlIHdpdGgKICAgIHJlc3BlY3QgdG8gdGhlIFdvcmssIG9yIHdobyBoYXMgcmVjZWl2ZWQgZXhwcmVzcyBwZXJtaXNzaW9uIGZyb20gdGhlCiAgICBMaWNlbnNvciB0byBleGVyY2lzZSByaWdodHMgdW5kZXIgdGhpcyBMaWNlbnNlIGRlc3BpdGUgYSBwcmV2aW91cwogICAgdmlvbGF0aW9uLgogai4gIlB1YmxpY2x5IFBlcmZvcm0iIG1lYW5zIHRvIHBlcmZvcm0gcHVibGljIHJlY2l0YXRpb25zIG9mIHRoZSBXb3JrIGFuZAogICAgdG8gY29tbXVuaWNhdGUgdG8gdGhlIHB1YmxpYyB0aG9zZSBwdWJsaWMgcmVjaXRhdGlvbnMsIGJ5IGFueSBtZWFucyBvcgogICAgcHJvY2VzcywgaW5jbHVkaW5nIGJ5IHdpcmUgb3Igd2lyZWxlc3MgbWVhbnMgb3IgcHVibGljIGRpZ2l0YWwKICAgIHBlcmZvcm1hbmNlczsgdG8gbWFrZSBhdmFpbGFibGUgdG8gdGhlIHB1YmxpYyBXb3JrcyBpbiBzdWNoIGEgd2F5IHRoYXQKICAgIG1lbWJlcnMgb2YgdGhlIHB1YmxpYyBtYXkgYWNjZXNzIHRoZXNlIFdvcmtzIGZyb20gYSBwbGFjZSBhbmQgYXQgYQogICAgcGxhY2UgaW5kaXZpZHVhbGx5IGNob3NlbiBieSB0aGVtOyB0byBwZXJmb3JtIHRoZSBXb3JrIHRvIHRoZSBwdWJsaWMKICAgIGJ5IGFueSBtZWFucyBvciBwcm9jZXNzIGFuZCB0aGUgY29tbXVuaWNhdGlvbiB0byB0aGUgcHVibGljIG9mIHRoZQogICAgcGVyZm9ybWFuY2VzIG9mIHRoZSBXb3JrLCBpbmNsdWRpbmcgYnkgcHVibGljIGRpZ2l0YWwgcGVyZm9ybWFuY2U7IHRvCiAgICBicm9hZGNhc3QgYW5kIHJlYnJvYWRjYXN0IHRoZSBXb3JrIGJ5IGFueSBtZWFucyBpbmNsdWRpbmcgc2lnbnMsCiAgICBzb3VuZHMgb3IgaW1hZ2VzLgogay4gIlJlcHJvZHVjZSIgbWVhbnMgdG8gbWFrZSBjb3BpZXMgb2YgdGhlIFdvcmsgYnkgYW55IG1lYW5zIGluY2x1ZGluZwogICAgd2l0aG91dCBsaW1pdGF0aW9uIGJ5IHNvdW5kIG9yIHZpc3VhbCByZWNvcmRpbmdzIGFuZCB0aGUgcmlnaHQgb2YKICAgIGZpeGF0aW9uIGFuZCByZXByb2R1Y2luZyBmaXhhdGlvbnMgb2YgdGhlIFdvcmssIGluY2x1ZGluZyBzdG9yYWdlIG9mIGEKICAgIHByb3RlY3RlZCBwZXJmb3JtYW5jZSBvciBwaG9ub2dyYW0gaW4gZGlnaXRhbCBmb3JtIG9yIG90aGVyIGVsZWN0cm9uaWMKICAgIG1lZGl1bS4KCjIuIEZhaXIgRGVhbGluZyBSaWdodHMuIE5vdGhpbmcgaW4gdGhpcyBMaWNlbnNlIGlzIGludGVuZGVkIHRvIHJlZHVjZSwKbGltaXQsIG9yIHJlc3RyaWN0IGFueSB1c2VzIGZyZWUgZnJvbSBjb3B5cmlnaHQgb3IgcmlnaHRzIGFyaXNpbmcgZnJvbQpsaW1pdGF0aW9ucyBvciBleGNlcHRpb25zIHRoYXQgYXJlIHByb3ZpZGVkIGZvciBpbiBjb25uZWN0aW9uIHdpdGggdGhlCmNvcHlyaWdodCBwcm90ZWN0aW9uIHVuZGVyIGNvcHlyaWdodCBsYXcgb3Igb3RoZXIgYXBwbGljYWJsZSBsYXdzLgoKMy4gTGljZW5zZSBHcmFudC4gU3ViamVjdCB0byB0aGUgdGVybXMgYW5kIGNvbmRpdGlvbnMgb2YgdGhpcyBMaWNlbnNlLApMaWNlbnNvciBoZXJlYnkgZ3JhbnRzIFlvdSBhIHdvcmxkd2lkZSwgcm95YWx0eS1mcmVlLCBub24tZXhjbHVzaXZlLApwZXJwZXR1YWwgKGZvciB0aGUgZHVyYXRpb24gb2YgdGhlIGFwcGxpY2FibGUgY29weXJpZ2h0KSBsaWNlbnNlIHRvCmV4ZXJjaXNlIHRoZSByaWdodHMgaW4gdGhlIFdvcmsgYXMgc3RhdGVkIGJlbG93OgoKIGEuIHRvIFJlcHJvZHVjZSB0aGUgV29yaywgdG8gaW5jb3Jwb3JhdGUgdGhlIFdvcmsgaW50byBvbmUgb3IgbW9yZQogICAgQ29sbGVjdGlvbnMsIGFuZCB0byBSZXByb2R1Y2UgdGhlIFdvcmsgYXMgaW5jb3Jwb3JhdGVkIGluIHRoZQogICAgQ29sbGVjdGlvbnM7CiBiLiB0byBjcmVhdGUgYW5kIFJlcHJvZHVjZSBBZGFwdGF0aW9ucyBwcm92aWRlZCB0aGF0IGFueSBzdWNoIEFkYXB0YXRpb24sCiAgICBpbmNsdWRpbmcgYW55IHRyYW5zbGF0aW9uIGluIGFueSBtZWRpdW0sIHRha2VzIHJlYXNvbmFibGUgc3RlcHMgdG8KICAgIGNsZWFybHkgbGFiZWwsIGRlbWFyY2F0ZSBvciBvdGhlcndpc2UgaWRlbnRpZnkgdGhhdCBjaGFuZ2VzIHdlcmUgbWFkZQogICAgdG8gdGhlIG9yaWdpbmFsIFdvcmsuIEZvciBleGFtcGxlLCBhIHRyYW5zbGF0aW9uIGNvdWxkIGJlIG1hcmtlZCAiVGhlCiAgICBvcmlnaW5hbCB3b3JrIHdhcyB0cmFuc2xhdGVkIGZyb20gRW5nbGlzaCB0byBTcGFuaXNoLCIgb3IgYQogICAgbW9kaWZpY2F0aW9uIGNvdWxkIGluZGljYXRlICJUaGUgb3JpZ2luYWwgd29yayBoYXMgYmVlbiBtb2RpZmllZC4iOwogYy4gdG8gRGlzdHJpYnV0ZSBhbmQgUHVibGljbHkgUGVyZm9ybSB0aGUgV29yayBpbmNsdWRpbmcgYXMgaW5jb3Jwb3JhdGVkCiAgICBpbiBDb2xsZWN0aW9uczsgYW5kLAogZC4gdG8gRGlzdHJpYnV0ZSBhbmQgUHVibGljbHkgUGVyZm9ybSBBZGFwdGF0aW9ucy4KIGUuIEZvciB0aGUgYXZvaWRhbmNlIG9mIGRvdWJ0OgoKICAgICBpLiBOb24td2FpdmFibGUgQ29tcHVsc29yeSBMaWNlbnNlIFNjaGVtZXMuIEluIHRob3NlIGp1cmlzZGljdGlvbnMgaW4KICAgICAgICB3aGljaCB0aGUgcmlnaHQgdG8gY29sbGVjdCByb3lhbHRpZXMgdGhyb3VnaCBhbnkgc3RhdHV0b3J5IG9yCiAgICAgICAgY29tcHVsc29yeSBsaWNlbnNpbmcgc2NoZW1lIGNhbm5vdCBiZSB3YWl2ZWQsIHRoZSBMaWNlbnNvcgogICAgICAgIHJlc2VydmVzIHRoZSBleGNsdXNpdmUgcmlnaHQgdG8gY29sbGVjdCBzdWNoIHJveWFsdGllcyBmb3IgYW55CiAgICAgICAgZXhlcmNpc2UgYnkgWW91IG9mIHRoZSByaWdodHMgZ3JhbnRlZCB1bmRlciB0aGlzIExpY2Vuc2U7CiAgICBpaS4gV2FpdmFibGUgQ29tcHVsc29yeSBMaWNlbnNlIFNjaGVtZXMuIEluIHRob3NlIGp1cmlzZGljdGlvbnMgaW4KICAgICAgICB3aGljaCB0aGUgcmlnaHQgdG8gY29sbGVjdCByb3lhbHRpZXMgdGhyb3VnaCBhbnkgc3RhdHV0b3J5IG9yCiAgICAgICAgY29tcHVsc29yeSBsaWNlbnNpbmcgc2NoZW1lIGNhbiBiZSB3YWl2ZWQsIHRoZSBMaWNlbnNvciB3YWl2ZXMgdGhlCiAgICAgICAgZXhjbHVzaXZlIHJpZ2h0IHRvIGNvbGxlY3Qgc3VjaCByb3lhbHRpZXMgZm9yIGFueSBleGVyY2lzZSBieSBZb3UKICAgICAgICBvZiB0aGUgcmlnaHRzIGdyYW50ZWQgdW5kZXIgdGhpcyBMaWNlbnNlOyBhbmQsCiAgIGlpaS4gVm9sdW50YXJ5IExpY2Vuc2UgU2NoZW1lcy4gVGhlIExpY2Vuc29yIHdhaXZlcyB0aGUgcmlnaHQgdG8KICAgICAgICBjb2xsZWN0IHJveWFsdGllcywgd2hldGhlciBpbmRpdmlkdWFsbHkgb3IsIGluIHRoZSBldmVudCB0aGF0IHRoZQogICAgICAgIExpY2Vuc29yIGlzIGEgbWVtYmVyIG9mIGEgY29sbGVjdGluZyBzb2NpZXR5IHRoYXQgYWRtaW5pc3RlcnMKICAgICAgICB2b2x1bnRhcnkgbGljZW5zaW5nIHNjaGVtZXMsIHZpYSB0aGF0IHNvY2lldHksIGZyb20gYW55IGV4ZXJjaXNlCiAgICAgICAgYnkgWW91IG9mIHRoZSByaWdodHMgZ3JhbnRlZCB1bmRlciB0aGlzIExpY2Vuc2UuCgpUaGUgYWJvdmUgcmlnaHRzIG1heSBiZSBleGVyY2lzZWQgaW4gYWxsIG1lZGlhIGFuZCBmb3JtYXRzIHdoZXRoZXIgbm93Cmtub3duIG9yIGhlcmVhZnRlciBkZXZpc2VkLiBUaGUgYWJvdmUgcmlnaHRzIGluY2x1ZGUgdGhlIHJpZ2h0IHRvIG1ha2UKc3VjaCBtb2RpZmljYXRpb25zIGFzIGFyZSB0ZWNobmljYWxseSBuZWNlc3NhcnkgdG8gZXhlcmNpc2UgdGhlIHJpZ2h0cyBpbgpvdGhlciBtZWRpYSBhbmQgZm9ybWF0cy4gU3ViamVjdCB0byBTZWN0aW9uIDgoZiksIGFsbCByaWdodHMgbm90IGV4cHJlc3NseQpncmFudGVkIGJ5IExpY2Vuc29yIGFyZSBoZXJlYnkgcmVzZXJ2ZWQuCgo0LiBSZXN0cmljdGlvbnMuIFRoZSBsaWNlbnNlIGdyYW50ZWQgaW4gU2VjdGlvbiAzIGFib3ZlIGlzIGV4cHJlc3NseSBtYWRlCnN1YmplY3QgdG8gYW5kIGxpbWl0ZWQgYnkgdGhlIGZvbGxvd2luZyByZXN0cmljdGlvbnM6CgogYS4gWW91IG1heSBEaXN0cmlidXRlIG9yIFB1YmxpY2x5IFBlcmZvcm0gdGhlIFdvcmsgb25seSB1bmRlciB0aGUgdGVybXMKICAgIG9mIHRoaXMgTGljZW5zZS4gWW91IG11c3QgaW5jbHVkZSBhIGNvcHkgb2YsIG9yIHRoZSBVbmlmb3JtIFJlc291cmNlCiAgICBJZGVudGlmaWVyIChVUkkpIGZvciwgdGhpcyBMaWNlbnNlIHdpdGggZXZlcnkgY29weSBvZiB0aGUgV29yayBZb3UKICAgIERpc3RyaWJ1dGUgb3IgUHVibGljbHkgUGVyZm9ybS4gWW91IG1heSBub3Qgb2ZmZXIgb3IgaW1wb3NlIGFueSB0ZXJtcwogICAgb24gdGhlIFdvcmsgdGhhdCByZXN0cmljdCB0aGUgdGVybXMgb2YgdGhpcyBMaWNlbnNlIG9yIHRoZSBhYmlsaXR5IG9mCiAgICB0aGUgcmVjaXBpZW50IG9mIHRoZSBXb3JrIHRvIGV4ZXJjaXNlIHRoZSByaWdodHMgZ3JhbnRlZCB0byB0aGF0CiAgICByZWNpcGllbnQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBMaWNlbnNlLiBZb3UgbWF5IG5vdCBzdWJsaWNlbnNlIHRoZQogICAgV29yay4gWW91IG11c3Qga2VlcCBpbnRhY3QgYWxsIG5vdGljZXMgdGhhdCByZWZlciB0byB0aGlzIExpY2Vuc2UgYW5kCiAgICB0byB0aGUgZGlzY2xhaW1lciBvZiB3YXJyYW50aWVzIHdpdGggZXZlcnkgY29weSBvZiB0aGUgV29yayBZb3UKICAgIERpc3RyaWJ1dGUgb3IgUHVibGljbHkgUGVyZm9ybS4gV2hlbiBZb3UgRGlzdHJpYnV0ZSBvciBQdWJsaWNseQogICAgUGVyZm9ybSB0aGUgV29yaywgWW91IG1heSBub3QgaW1wb3NlIGFueSBlZmZlY3RpdmUgdGVjaG5vbG9naWNhbAogICAgbWVhc3VyZXMgb24gdGhlIFdvcmsgdGhhdCByZXN0cmljdCB0aGUgYWJpbGl0eSBvZiBhIHJlY2lwaWVudCBvZiB0aGUKICAgIFdvcmsgZnJvbSBZb3UgdG8gZXhlcmNpc2UgdGhlIHJpZ2h0cyBncmFudGVkIHRvIHRoYXQgcmVjaXBpZW50IHVuZGVyCiAgICB0aGUgdGVybXMgb2YgdGhlIExpY2Vuc2UuIFRoaXMgU2VjdGlvbiA0KGEpIGFwcGxpZXMgdG8gdGhlIFdvcmsgYXMKICAgIGluY29ycG9yYXRlZCBpbiBhIENvbGxlY3Rpb24sIGJ1dCB0aGlzIGRvZXMgbm90IHJlcXVpcmUgdGhlIENvbGxlY3Rpb24KICAgIGFwYXJ0IGZyb20gdGhlIFdvcmsgaXRzZWxmIHRvIGJlIG1hZGUgc3ViamVjdCB0byB0aGUgdGVybXMgb2YgdGhpcwogICAgTGljZW5zZS4gSWYgWW91IGNyZWF0ZSBhIENvbGxlY3Rpb24sIHVwb24gbm90aWNlIGZyb20gYW55IExpY2Vuc29yIFlvdQogICAgbXVzdCwgdG8gdGhlIGV4dGVudCBwcmFjdGljYWJsZSwgcmVtb3ZlIGZyb20gdGhlIENvbGxlY3Rpb24gYW55IGNyZWRpdAogICAgYXMgcmVxdWlyZWQgYnkgU2VjdGlvbiA0KGMpLCBhcyByZXF1ZXN0ZWQuIElmIFlvdSBjcmVhdGUgYW4KICAgIEFkYXB0YXRpb24sIHVwb24gbm90aWNlIGZyb20gYW55IExpY2Vuc29yIFlvdSBtdXN0LCB0byB0aGUgZXh0ZW50CiAgICBwcmFjdGljYWJsZSwgcmVtb3ZlIGZyb20gdGhlIEFkYXB0YXRpb24gYW55IGNyZWRpdCBhcyByZXF1aXJlZCBieQogICAgU2VjdGlvbiA0KGMpLCBhcyByZXF1ZXN0ZWQuCiBiLiBZb3UgbWF5IERpc3RyaWJ1dGUgb3IgUHVibGljbHkgUGVyZm9ybSBhbiBBZGFwdGF0aW9uIG9ubHkgdW5kZXIgdGhlCiAgICB0ZXJtcyBvZjogKGkpIHRoaXMgTGljZW5zZTsgKGlpKSBhIGxhdGVyIHZlcnNpb24gb2YgdGhpcyBMaWNlbnNlIHdpdGgKICAgIHRoZSBzYW1lIExpY2Vuc2UgRWxlbWVudHMgYXMgdGhpcyBMaWNlbnNlOyAoaWlpKSBhIENyZWF0aXZlIENvbW1vbnMKICAgIGp1cmlzZGljdGlvbiBsaWNlbnNlIChlaXRoZXIgdGhpcyBvciBhIGxhdGVyIGxpY2Vuc2UgdmVyc2lvbikgdGhhdAogICAgY29udGFpbnMgdGhlIHNhbWUgTGljZW5zZSBFbGVtZW50cyBhcyB0aGlzIExpY2Vuc2UgKGUuZy4sCiAgICBBdHRyaWJ1dGlvbi1TaGFyZUFsaWtlIDMuMCBVUykpOyAoaXYpIGEgQ3JlYXRpdmUgQ29tbW9ucyBDb21wYXRpYmxlCiAgICBMaWNlbnNlLiBJZiB5b3UgbGljZW5zZSB0aGUgQWRhcHRhdGlvbiB1bmRlciBvbmUgb2YgdGhlIGxpY2Vuc2VzCiAgICBtZW50aW9uZWQgaW4gKGl2KSwgeW91IG11c3QgY29tcGx5IHdpdGggdGhlIHRlcm1zIG9mIHRoYXQgbGljZW5zZS4gSWYKICAgIHlvdSBsaWNlbnNlIHRoZSBBZGFwdGF0aW9uIHVuZGVyIHRoZSB0ZXJtcyBvZiBhbnkgb2YgdGhlIGxpY2Vuc2VzCiAgICBtZW50aW9uZWQgaW4gKGkpLCAoaWkpIG9yIChpaWkpICh0aGUgIkFwcGxpY2FibGUgTGljZW5zZSIpLCB5b3UgbXVzdAogICAgY29tcGx5IHdpdGggdGhlIHRlcm1zIG9mIHRoZSBBcHBsaWNhYmxlIExpY2Vuc2UgZ2VuZXJhbGx5IGFuZCB0aGUKICAgIGZvbGxvd2luZyBwcm92aXNpb25zOiAoSSkgWW91IG11c3QgaW5jbHVkZSBhIGNvcHkgb2YsIG9yIHRoZSBVUkkgZm9yLAogICAgdGhlIEFwcGxpY2FibGUgTGljZW5zZSB3aXRoIGV2ZXJ5IGNvcHkgb2YgZWFjaCBBZGFwdGF0aW9uIFlvdQogICAgRGlzdHJpYnV0ZSBvciBQdWJsaWNseSBQZXJmb3JtOyAoSUkpIFlvdSBtYXkgbm90IG9mZmVyIG9yIGltcG9zZSBhbnkKICAgIHRlcm1zIG9uIHRoZSBBZGFwdGF0aW9uIHRoYXQgcmVzdHJpY3QgdGhlIHRlcm1zIG9mIHRoZSBBcHBsaWNhYmxlCiAgICBMaWNlbnNlIG9yIHRoZSBhYmlsaXR5IG9mIHRoZSByZWNpcGllbnQgb2YgdGhlIEFkYXB0YXRpb24gdG8gZXhlcmNpc2UKICAgIHRoZSByaWdodHMgZ3JhbnRlZCB0byB0aGF0IHJlY2lwaWVudCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEFwcGxpY2FibGUKICAgIExpY2Vuc2U7IChJSUkpIFlvdSBtdXN0IGtlZXAgaW50YWN0IGFsbCBub3RpY2VzIHRoYXQgcmVmZXIgdG8gdGhlCiAgICBBcHBsaWNhYmxlIExpY2Vuc2UgYW5kIHRvIHRoZSBkaXNjbGFpbWVyIG9mIHdhcnJhbnRpZXMgd2l0aCBldmVyeSBjb3B5CiAgICBvZiB0aGUgV29yayBhcyBpbmNsdWRlZCBpbiB0aGUgQWRhcHRhdGlvbiBZb3UgRGlzdHJpYnV0ZSBvciBQdWJsaWNseQogICAgUGVyZm9ybTsgKElWKSB3aGVuIFlvdSBEaXN0cmlidXRlIG9yIFB1YmxpY2x5IFBlcmZvcm0gdGhlIEFkYXB0YXRpb24sCiAgICBZb3UgbWF5IG5vdCBpbXBvc2UgYW55IGVmZmVjdGl2ZSB0ZWNobm9sb2dpY2FsIG1lYXN1cmVzIG9uIHRoZQogICAgQWRhcHRhdGlvbiB0aGF0IHJlc3RyaWN0IHRoZSBhYmlsaXR5IG9mIGEgcmVjaXBpZW50IG9mIHRoZSBBZGFwdGF0aW9uCiAgICBmcm9tIFlvdSB0byBleGVyY2lzZSB0aGUgcmlnaHRzIGdyYW50ZWQgdG8gdGhhdCByZWNpcGllbnQgdW5kZXIgdGhlCiAgICB0ZXJtcyBvZiB0aGUgQXBwbGljYWJsZSBMaWNlbnNlLiBUaGlzIFNlY3Rpb24gNChiKSBhcHBsaWVzIHRvIHRoZQogICAgQWRhcHRhdGlvbiBhcyBpbmNvcnBvcmF0ZWQgaW4gYSBDb2xsZWN0aW9uLCBidXQgdGhpcyBkb2VzIG5vdCByZXF1aXJlCiAgICB0aGUgQ29sbGVjdGlvbiBhcGFydCBmcm9tIHRoZSBBZGFwdGF0aW9uIGl0c2VsZiB0byBiZSBtYWRlIHN1YmplY3QgdG8KICAgIHRoZSB0ZXJtcyBvZiB0aGUgQXBwbGljYWJsZSBMaWNlbnNlLgogYy4gSWYgWW91IERpc3RyaWJ1dGUsIG9yIFB1YmxpY2x5IFBlcmZvcm0gdGhlIFdvcmsgb3IgYW55IEFkYXB0YXRpb25zIG9yCiAgICBDb2xsZWN0aW9ucywgWW91IG11c3QsIHVubGVzcyBhIHJlcXVlc3QgaGFzIGJlZW4gbWFkZSBwdXJzdWFudCB0bwogICAgU2VjdGlvbiA0KGEpLCBrZWVwIGludGFjdCBhbGwgY29weXJpZ2h0IG5vdGljZXMgZm9yIHRoZSBXb3JrIGFuZAogICAgcHJvdmlkZSwgcmVhc29uYWJsZSB0byB0aGUgbWVkaXVtIG9yIG1lYW5zIFlvdSBhcmUgdXRpbGl6aW5nOiAoaSkgdGhlCiAgICBuYW1lIG9mIHRoZSBPcmlnaW5hbCBBdXRob3IgKG9yIHBzZXVkb255bSwgaWYgYXBwbGljYWJsZSkgaWYgc3VwcGxpZWQsCiAgICBhbmQvb3IgaWYgdGhlIE9yaWdpbmFsIEF1dGhvciBhbmQvb3IgTGljZW5zb3IgZGVzaWduYXRlIGFub3RoZXIgcGFydHkKICAgIG9yIHBhcnRpZXMgKGUuZy4sIGEgc3BvbnNvciBpbnN0aXR1dGUsIHB1Ymxpc2hpbmcgZW50aXR5LCBqb3VybmFsKSBmb3IKICAgIGF0dHJpYnV0aW9uICgiQXR0cmlidXRpb24gUGFydGllcyIpIGluIExpY2Vuc29yJ3MgY29weXJpZ2h0IG5vdGljZSwKICAgIHRlcm1zIG9mIHNlcnZpY2Ugb3IgYnkgb3RoZXIgcmVhc29uYWJsZSBtZWFucywgdGhlIG5hbWUgb2Ygc3VjaCBwYXJ0eQogICAgb3IgcGFydGllczsgKGlpKSB0aGUgdGl0bGUgb2YgdGhlIFdvcmsgaWYgc3VwcGxpZWQ7IChpaWkpIHRvIHRoZQogICAgZXh0ZW50IHJlYXNvbmFibHkgcHJhY3RpY2FibGUsIHRoZSBVUkksIGlmIGFueSwgdGhhdCBMaWNlbnNvcgogICAgc3BlY2lmaWVzIHRvIGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgV29yaywgdW5sZXNzIHN1Y2ggVVJJIGRvZXMgbm90CiAgICByZWZlciB0byB0aGUgY29weXJpZ2h0IG5vdGljZSBvciBsaWNlbnNpbmcgaW5mb3JtYXRpb24gZm9yIHRoZSBXb3JrOwogICAgYW5kIChpdikgLCBjb25zaXN0ZW50IHdpdGggU3NlY3Rpb24gMyhiKSwgaW4gdGhlIGNhc2Ugb2YgYW4KICAgIEFkYXB0YXRpb24sIGEgY3JlZGl0IGlkZW50aWZ5aW5nIHRoZSB1c2Ugb2YgdGhlIFdvcmsgaW4gdGhlIEFkYXB0YXRpb24KICAgIChlLmcuLCAiRnJlbmNoIHRyYW5zbGF0aW9uIG9mIHRoZSBXb3JrIGJ5IE9yaWdpbmFsIEF1dGhvciwiIG9yCiAgICAiU2NyZWVucGxheSBiYXNlZCBvbiBvcmlnaW5hbCBXb3JrIGJ5IE9yaWdpbmFsIEF1dGhvciIpLiBUaGUgY3JlZGl0CiAgICByZXF1aXJlZCBieSB0aGlzIFNlY3Rpb24gNChjKSBtYXkgYmUgaW1wbGVtZW50ZWQgaW4gYW55IHJlYXNvbmFibGUKICAgIG1hbm5lcjsgcHJvdmlkZWQsIGhvd2V2ZXIsIHRoYXQgaW4gdGhlIGNhc2Ugb2YgYSBBZGFwdGF0aW9uIG9yCiAgICBDb2xsZWN0aW9uLCBhdCBhIG1pbmltdW0gc3VjaCBjcmVkaXQgd2lsbCBhcHBlYXIsIGlmIGEgY3JlZGl0IGZvciBhbGwKICAgIGNvbnRyaWJ1dGluZyBhdXRob3JzIG9mIHRoZSBBZGFwdGF0aW9uIG9yIENvbGxlY3Rpb24gYXBwZWFycywgdGhlbiBhcwogICAgcGFydCBvZiB0aGVzZSBjcmVkaXRzIGFuZCBpbiBhIG1hbm5lciBhdCBsZWFzdCBhcyBwcm9taW5lbnQgYXMgdGhlCiAgICBjcmVkaXRzIGZvciB0aGUgb3RoZXIgY29udHJpYnV0aW5nIGF1dGhvcnMuIEZvciB0aGUgYXZvaWRhbmNlIG9mCiAgICBkb3VidCwgWW91IG1heSBvbmx5IHVzZSB0aGUgY3JlZGl0IHJlcXVpcmVkIGJ5IHRoaXMgU2VjdGlvbiBmb3IgdGhlCiAgICBwdXJwb3NlIG9mIGF0dHJpYnV0aW9uIGluIHRoZSBtYW5uZXIgc2V0IG91dCBhYm92ZSBhbmQsIGJ5IGV4ZXJjaXNpbmcKICAgIFlvdXIgcmlnaHRzIHVuZGVyIHRoaXMgTGljZW5zZSwgWW91IG1heSBub3QgaW1wbGljaXRseSBvciBleHBsaWNpdGx5CiAgICBhc3NlcnQgb3IgaW1wbHkgYW55IGNvbm5lY3Rpb24gd2l0aCwgc3BvbnNvcnNoaXAgb3IgZW5kb3JzZW1lbnQgYnkgdGhlCiAgICBPcmlnaW5hbCBBdXRob3IsIExpY2Vuc29yIGFuZC9vciBBdHRyaWJ1dGlvbiBQYXJ0aWVzLCBhcyBhcHByb3ByaWF0ZSwKICAgIG9mIFlvdSBvciBZb3VyIHVzZSBvZiB0aGUgV29yaywgd2l0aG91dCB0aGUgc2VwYXJhdGUsIGV4cHJlc3MgcHJpb3IKICAgIHdyaXR0ZW4gcGVybWlzc2lvbiBvZiB0aGUgT3JpZ2luYWwgQXV0aG9yLCBMaWNlbnNvciBhbmQvb3IgQXR0cmlidXRpb24KICAgIFBhcnRpZXMuCiBkLiBFeGNlcHQgYXMgb3RoZXJ3aXNlIGFncmVlZCBpbiB3cml0aW5nIGJ5IHRoZSBMaWNlbnNvciBvciBhcyBtYXkgYmUKICAgIG90aGVyd2lzZSBwZXJtaXR0ZWQgYnkgYXBwbGljYWJsZSBsYXcsIGlmIFlvdSBSZXByb2R1Y2UsIERpc3RyaWJ1dGUgb3IKICAgIFB1YmxpY2x5IFBlcmZvcm0gdGhlIFdvcmsgZWl0aGVyIGJ5IGl0c2VsZiBvciBhcyBwYXJ0IG9mIGFueQogICAgQWRhcHRhdGlvbnMgb3IgQ29sbGVjdGlvbnMsIFlvdSBtdXN0IG5vdCBkaXN0b3J0LCBtdXRpbGF0ZSwgbW9kaWZ5IG9yCiAgICB0YWtlIG90aGVyIGRlcm9nYXRvcnkgYWN0aW9uIGluIHJlbGF0aW9uIHRvIHRoZSBXb3JrIHdoaWNoIHdvdWxkIGJlCiAgICBwcmVqdWRpY2lhbCB0byB0aGUgT3JpZ2luYWwgQXV0aG9yJ3MgaG9ub3Igb3IgcmVwdXRhdGlvbi4gTGljZW5zb3IKICAgIGFncmVlcyB0aGF0IGluIHRob3NlIGp1cmlzZGljdGlvbnMgKGUuZy4gSmFwYW4pLCBpbiB3aGljaCBhbnkgZXhlcmNpc2UKICAgIG9mIHRoZSByaWdodCBncmFudGVkIGluIFNlY3Rpb24gMyhiKSBvZiB0aGlzIExpY2Vuc2UgKHRoZSByaWdodCB0bwogICAgbWFrZSBBZGFwdGF0aW9ucykgd291bGQgYmUgZGVlbWVkIHRvIGJlIGEgZGlzdG9ydGlvbiwgbXV0aWxhdGlvbiwKICAgIG1vZGlmaWNhdGlvbiBvciBvdGhlciBkZXJvZ2F0b3J5IGFjdGlvbiBwcmVqdWRpY2lhbCB0byB0aGUgT3JpZ2luYWwKICAgIEF1dGhvcidzIGhvbm9yIGFuZCByZXB1dGF0aW9uLCB0aGUgTGljZW5zb3Igd2lsbCB3YWl2ZSBvciBub3QgYXNzZXJ0LAogICAgYXMgYXBwcm9wcmlhdGUsIHRoaXMgU2VjdGlvbiwgdG8gdGhlIGZ1bGxlc3QgZXh0ZW50IHBlcm1pdHRlZCBieSB0aGUKICAgIGFwcGxpY2FibGUgbmF0aW9uYWwgbGF3LCB0byBlbmFibGUgWW91IHRvIHJlYXNvbmFibHkgZXhlcmNpc2UgWW91cgogICAgcmlnaHQgdW5kZXIgU2VjdGlvbiAzKGIpIG9mIHRoaXMgTGljZW5zZSAocmlnaHQgdG8gbWFrZSBBZGFwdGF0aW9ucykKICAgIGJ1dCBub3Qgb3RoZXJ3aXNlLgoKNS4gUmVwcmVzZW50YXRpb25zLCBXYXJyYW50aWVzIGFuZCBEaXNjbGFpbWVyCgpVTkxFU1MgT1RIRVJXSVNFIE1VVFVBTExZIEFHUkVFRCBUTyBCWSBUSEUgUEFSVElFUyBJTiBXUklUSU5HLCBMSUNFTlNPUgpPRkZFUlMgVEhFIFdPUksgQVMtSVMgQU5EIE1BS0VTIE5PIFJFUFJFU0VOVEFUSU9OUyBPUiBXQVJSQU5USUVTIE9GIEFOWQpLSU5EIENPTkNFUk5JTkcgVEhFIFdPUkssIEVYUFJFU1MsIElNUExJRUQsIFNUQVRVVE9SWSBPUiBPVEhFUldJU0UsCklOQ0xVRElORywgV0lUSE9VVCBMSU1JVEFUSU9OLCBXQVJSQU5USUVTIE9GIFRJVExFLCBNRVJDSEFOVElCSUxJVFksCkZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLCBOT05JTkZSSU5HRU1FTlQsIE9SIFRIRSBBQlNFTkNFIE9GCkxBVEVOVCBPUiBPVEhFUiBERUZFQ1RTLCBBQ0NVUkFDWSwgT1IgVEhFIFBSRVNFTkNFIE9GIEFCU0VOQ0UgT0YgRVJST1JTLApXSEVUSEVSIE9SIE5PVCBESVNDT1ZFUkFCTEUuIFNPTUUgSlVSSVNESUNUSU9OUyBETyBOT1QgQUxMT1cgVEhFIEVYQ0xVU0lPTgpPRiBJTVBMSUVEIFdBUlJBTlRJRVMsIFNPIFNVQ0ggRVhDTFVTSU9OIE1BWSBOT1QgQVBQTFkgVE8gWU9VLgoKNi4gTGltaXRhdGlvbiBvbiBMaWFiaWxpdHkuIEVYQ0VQVCBUTyBUSEUgRVhURU5UIFJFUVVJUkVEIEJZIEFQUExJQ0FCTEUKTEFXLCBJTiBOTyBFVkVOVCBXSUxMIExJQ0VOU09SIEJFIExJQUJMRSBUTyBZT1UgT04gQU5ZIExFR0FMIFRIRU9SWSBGT1IKQU5ZIFNQRUNJQUwsIElOQ0lERU5UQUwsIENPTlNFUVVFTlRJQUwsIFBVTklUSVZFIE9SIEVYRU1QTEFSWSBEQU1BR0VTCkFSSVNJTkcgT1VUIE9GIFRISVMgTElDRU5TRSBPUiBUSEUgVVNFIE9GIFRIRSBXT1JLLCBFVkVOIElGIExJQ0VOU09SIEhBUwpCRUVOIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFUy4KCjcuIFRlcm1pbmF0aW9uCgogYS4gVGhpcyBMaWNlbnNlIGFuZCB0aGUgcmlnaHRzIGdyYW50ZWQgaGVyZXVuZGVyIHdpbGwgdGVybWluYXRlCiAgICBhdXRvbWF0aWNhbGx5IHVwb24gYW55IGJyZWFjaCBieSBZb3Ugb2YgdGhlIHRlcm1zIG9mIHRoaXMgTGljZW5zZS4KICAgIEluZGl2aWR1YWxzIG9yIGVudGl0aWVzIHdobyBoYXZlIHJlY2VpdmVkIEFkYXB0YXRpb25zIG9yIENvbGxlY3Rpb25zCiAgICBmcm9tIFlvdSB1bmRlciB0aGlzIExpY2Vuc2UsIGhvd2V2ZXIsIHdpbGwgbm90IGhhdmUgdGhlaXIgbGljZW5zZXMKICAgIHRlcm1pbmF0ZWQgcHJvdmlkZWQgc3VjaCBpbmRpdmlkdWFscyBvciBlbnRpdGllcyByZW1haW4gaW4gZnVsbAogICAgY29tcGxpYW5jZSB3aXRoIHRob3NlIGxpY2Vuc2VzLiBTZWN0aW9ucyAxLCAyLCA1LCA2LCA3LCBhbmQgOCB3aWxsCiAgICBzdXJ2aXZlIGFueSB0ZXJtaW5hdGlvbiBvZiB0aGlzIExpY2Vuc2UuCiBiLiBTdWJqZWN0IHRvIHRoZSBhYm92ZSB0ZXJtcyBhbmQgY29uZGl0aW9ucywgdGhlIGxpY2Vuc2UgZ3JhbnRlZCBoZXJlIGlzCiAgICBwZXJwZXR1YWwgKGZvciB0aGUgZHVyYXRpb24gb2YgdGhlIGFwcGxpY2FibGUgY29weXJpZ2h0IGluIHRoZSBXb3JrKS4KICAgIE5vdHdpdGhzdGFuZGluZyB0aGUgYWJvdmUsIExpY2Vuc29yIHJlc2VydmVzIHRoZSByaWdodCB0byByZWxlYXNlIHRoZQogICAgV29yayB1bmRlciBkaWZmZXJlbnQgbGljZW5zZSB0ZXJtcyBvciB0byBzdG9wIGRpc3RyaWJ1dGluZyB0aGUgV29yayBhdAogICAgYW55IHRpbWU7IHByb3ZpZGVkLCBob3dldmVyIHRoYXQgYW55IHN1Y2ggZWxlY3Rpb24gd2lsbCBub3Qgc2VydmUgdG8KICAgIHdpdGhkcmF3IHRoaXMgTGljZW5zZSAob3IgYW55IG90aGVyIGxpY2Vuc2UgdGhhdCBoYXMgYmVlbiwgb3IgaXMKICAgIHJlcXVpcmVkIHRvIGJlLCBncmFudGVkIHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGlzIExpY2Vuc2UpLCBhbmQgdGhpcwogICAgTGljZW5zZSB3aWxsIGNvbnRpbnVlIGluIGZ1bGwgZm9yY2UgYW5kIGVmZmVjdCB1bmxlc3MgdGVybWluYXRlZCBhcwogICAgc3RhdGVkIGFib3ZlLgoKOC4gTWlzY2VsbGFuZW91cwoKIGEuIEVhY2ggdGltZSBZb3UgRGlzdHJpYnV0ZSBvciBQdWJsaWNseSBQZXJmb3JtIHRoZSBXb3JrIG9yIGEgQ29sbGVjdGlvbiwKICAgIHRoZSBMaWNlbnNvciBvZmZlcnMgdG8gdGhlIHJlY2lwaWVudCBhIGxpY2Vuc2UgdG8gdGhlIFdvcmsgb24gdGhlIHNhbWUKICAgIHRlcm1zIGFuZCBjb25kaXRpb25zIGFzIHRoZSBsaWNlbnNlIGdyYW50ZWQgdG8gWW91IHVuZGVyIHRoaXMgTGljZW5zZS4KIGIuIEVhY2ggdGltZSBZb3UgRGlzdHJpYnV0ZSBvciBQdWJsaWNseSBQZXJmb3JtIGFuIEFkYXB0YXRpb24sIExpY2Vuc29yCiAgICBvZmZlcnMgdG8gdGhlIHJlY2lwaWVudCBhIGxpY2Vuc2UgdG8gdGhlIG9yaWdpbmFsIFdvcmsgb24gdGhlIHNhbWUKICAgIHRlcm1zIGFuZCBjb25kaXRpb25zIGFzIHRoZSBsaWNlbnNlIGdyYW50ZWQgdG8gWW91IHVuZGVyIHRoaXMgTGljZW5zZS4KIGMuIElmIGFueSBwcm92aXNpb24gb2YgdGhpcyBMaWNlbnNlIGlzIGludmFsaWQgb3IgdW5lbmZvcmNlYWJsZSB1bmRlcgogICAgYXBwbGljYWJsZSBsYXcsIGl0IHNoYWxsIG5vdCBhZmZlY3QgdGhlIHZhbGlkaXR5IG9yIGVuZm9yY2VhYmlsaXR5IG9mCiAgICB0aGUgcmVtYWluZGVyIG9mIHRoZSB0ZXJtcyBvZiB0aGlzIExpY2Vuc2UsIGFuZCB3aXRob3V0IGZ1cnRoZXIgYWN0aW9uCiAgICBieSB0aGUgcGFydGllcyB0byB0aGlzIGFncmVlbWVudCwgc3VjaCBwcm92aXNpb24gc2hhbGwgYmUgcmVmb3JtZWQgdG8KICAgIHRoZSBtaW5pbXVtIGV4dGVudCBuZWNlc3NhcnkgdG8gbWFrZSBzdWNoIHByb3Zpc2lvbiB2YWxpZCBhbmQKICAgIGVuZm9yY2VhYmxlLgogZC4gTm8gdGVybSBvciBwcm92aXNpb24gb2YgdGhpcyBMaWNlbnNlIHNoYWxsIGJlIGRlZW1lZCB3YWl2ZWQgYW5kIG5vCiAgICBicmVhY2ggY29uc2VudGVkIHRvIHVubGVzcyBzdWNoIHdhaXZlciBvciBjb25zZW50IHNoYWxsIGJlIGluIHdyaXRpbmcKICAgIGFuZCBzaWduZWQgYnkgdGhlIHBhcnR5IHRvIGJlIGNoYXJnZWQgd2l0aCBzdWNoIHdhaXZlciBvciBjb25zZW50LgogZS4gVGhpcyBMaWNlbnNlIGNvbnN0aXR1dGVzIHRoZSBlbnRpcmUgYWdyZWVtZW50IGJldHdlZW4gdGhlIHBhcnRpZXMgd2l0aAogICAgcmVzcGVjdCB0byB0aGUgV29yayBsaWNlbnNlZCBoZXJlLiBUaGVyZSBhcmUgbm8gdW5kZXJzdGFuZGluZ3MsCiAgICBhZ3JlZW1lbnRzIG9yIHJlcHJlc2VudGF0aW9ucyB3aXRoIHJlc3BlY3QgdG8gdGhlIFdvcmsgbm90IHNwZWNpZmllZAogICAgaGVyZS4gTGljZW5zb3Igc2hhbGwgbm90IGJlIGJvdW5kIGJ5IGFueSBhZGRpdGlvbmFsIHByb3Zpc2lvbnMgdGhhdAogICAgbWF5IGFwcGVhciBpbiBhbnkgY29tbXVuaWNhdGlvbiBmcm9tIFlvdS4gVGhpcyBMaWNlbnNlIG1heSBub3QgYmUKICAgIG1vZGlmaWVkIHdpdGhvdXQgdGhlIG11dHVhbCB3cml0dGVuIGFncmVlbWVudCBvZiB0aGUgTGljZW5zb3IgYW5kIFlvdS4KIGYuIFRoZSByaWdodHMgZ3JhbnRlZCB1bmRlciwgYW5kIHRoZSBzdWJqZWN0IG1hdHRlciByZWZlcmVuY2VkLCBpbiB0aGlzCiAgICBMaWNlbnNlIHdlcmUgZHJhZnRlZCB1dGlsaXppbmcgdGhlIHRlcm1pbm9sb2d5IG9mIHRoZSBCZXJuZSBDb252ZW50aW9uCiAgICBmb3IgdGhlIFByb3RlY3Rpb24gb2YgTGl0ZXJhcnkgYW5kIEFydGlzdGljIFdvcmtzIChhcyBhbWVuZGVkIG9uCiAgICBTZXB0ZW1iZXIgMjgsIDE5NzkpLCB0aGUgUm9tZSBDb252ZW50aW9uIG9mIDE5NjEsIHRoZSBXSVBPIENvcHlyaWdodAogICAgVHJlYXR5IG9mIDE5OTYsIHRoZSBXSVBPIFBlcmZvcm1hbmNlcyBhbmQgUGhvbm9ncmFtcyBUcmVhdHkgb2YgMTk5NgogICAgYW5kIHRoZSBVbml2ZXJzYWwgQ29weXJpZ2h0IENvbnZlbnRpb24gKGFzIHJldmlzZWQgb24gSnVseSAyNCwgMTk3MSkuCiAgICBUaGVzZSByaWdodHMgYW5kIHN1YmplY3QgbWF0dGVyIHRha2UgZWZmZWN0IGluIHRoZSByZWxldmFudAogICAganVyaXNkaWN0aW9uIGluIHdoaWNoIHRoZSBMaWNlbnNlIHRlcm1zIGFyZSBzb3VnaHQgdG8gYmUgZW5mb3JjZWQKICAgIGFjY29yZGluZyB0byB0aGUgY29ycmVzcG9uZGluZyBwcm92aXNpb25zIG9mIHRoZSBpbXBsZW1lbnRhdGlvbiBvZgogICAgdGhvc2UgdHJlYXR5IHByb3Zpc2lvbnMgaW4gdGhlIGFwcGxpY2FibGUgbmF0aW9uYWwgbGF3LiBJZiB0aGUKICAgIHN0YW5kYXJkIHN1aXRlIG9mIHJpZ2h0cyBncmFudGVkIHVuZGVyIGFwcGxpY2FibGUgY29weXJpZ2h0IGxhdwogICAgaW5jbHVkZXMgYWRkaXRpb25hbCByaWdodHMgbm90IGdyYW50ZWQgdW5kZXIgdGhpcyBMaWNlbnNlLCBzdWNoCiAgICBhZGRpdGlvbmFsIHJpZ2h0cyBhcmUgZGVlbWVkIHRvIGJlIGluY2x1ZGVkIGluIHRoZSBMaWNlbnNlOyB0aGlzCiAgICBMaWNlbnNlIGlzIG5vdCBpbnRlbmRlZCB0byByZXN0cmljdCB0aGUgbGljZW5zZSBvZiBhbnkgcmlnaHRzIHVuZGVyCiAgICBhcHBsaWNhYmxlIGxhdy4KCgpDcmVhdGl2ZSBDb21tb25zIE5vdGljZQoKICAgIENyZWF0aXZlIENvbW1vbnMgaXMgbm90IGEgcGFydHkgdG8gdGhpcyBMaWNlbnNlLCBhbmQgbWFrZXMgbm8gd2FycmFudHkKICAgIHdoYXRzb2V2ZXIgaW4gY29ubmVjdGlvbiB3aXRoIHRoZSBXb3JrLiBDcmVhdGl2ZSBDb21tb25zIHdpbGwgbm90IGJlCiAgICBsaWFibGUgdG8gWW91IG9yIGFueSBwYXJ0eSBvbiBhbnkgbGVnYWwgdGhlb3J5IGZvciBhbnkgZGFtYWdlcwogICAgd2hhdHNvZXZlciwgaW5jbHVkaW5nIHdpdGhvdXQgbGltaXRhdGlvbiBhbnkgZ2VuZXJhbCwgc3BlY2lhbCwKICAgIGluY2lkZW50YWwgb3IgY29uc2VxdWVudGlhbCBkYW1hZ2VzIGFyaXNpbmcgaW4gY29ubmVjdGlvbiB0byB0aGlzCiAgICBsaWNlbnNlLiBOb3R3aXRoc3RhbmRpbmcgdGhlIGZvcmVnb2luZyB0d28gKDIpIHNlbnRlbmNlcywgaWYgQ3JlYXRpdmUKICAgIENvbW1vbnMgaGFzIGV4cHJlc3NseSBpZGVudGlmaWVkIGl0c2VsZiBhcyB0aGUgTGljZW5zb3IgaGVyZXVuZGVyLCBpdAogICAgc2hhbGwgaGF2ZSBhbGwgcmlnaHRzIGFuZCBvYmxpZ2F0aW9ucyBvZiBMaWNlbnNvci4KCiAgICBFeGNlcHQgZm9yIHRoZSBsaW1pdGVkIHB1cnBvc2Ugb2YgaW5kaWNhdGluZyB0byB0aGUgcHVibGljIHRoYXQgdGhlCiAgICBXb3JrIGlzIGxpY2Vuc2VkIHVuZGVyIHRoZSBDQ1BMLCBDcmVhdGl2ZSBDb21tb25zIGRvZXMgbm90IGF1dGhvcml6ZQogICAgdGhlIHVzZSBieSBlaXRoZXIgcGFydHkgb2YgdGhlIHRyYWRlbWFyayAiQ3JlYXRpdmUgQ29tbW9ucyIgb3IgYW55CiAgICByZWxhdGVkIHRyYWRlbWFyayBvciBsb2dvIG9mIENyZWF0aXZlIENvbW1vbnMgd2l0aG91dCB0aGUgcHJpb3IKICAgIHdyaXR0ZW4gY29uc2VudCBvZiBDcmVhdGl2ZSBDb21tb25zLiBBbnkgcGVybWl0dGVkIHVzZSB3aWxsIGJlIGluCiAgICBjb21wbGlhbmNlIHdpdGggQ3JlYXRpdmUgQ29tbW9ucycgdGhlbi1jdXJyZW50IHRyYWRlbWFyayB1c2FnZQogICAgZ3VpZGVsaW5lcywgYXMgbWF5IGJlIHB1Ymxpc2hlZCBvbiBpdHMgd2Vic2l0ZSBvciBvdGhlcndpc2UgbWFkZQogICAgYXZhaWxhYmxlIHVwb24gcmVxdWVzdCBmcm9tIHRpbWUgdG8gdGltZS4gRm9yIHRoZSBhdm9pZGFuY2Ugb2YgZG91YnQsCiAgICB0aGlzIHRyYWRlbWFyayByZXN0cmljdGlvbiBkb2VzIG5vdCBmb3JtIHBhcnQgb2YgdGhlIExpY2Vuc2UuCgogICAgQ3JlYXRpdmUgQ29tbW9ucyBtYXkgYmUgY29udGFjdGVkIGF0IGh0dHBzOi8vY3JlYXRpdmVjb21tb25zLm9yZy8u"
          },
          "url": "https://creativecommons.org/licenses/by-sa/3.0/legalcode"
        }
      }
    ]
  },
  "definitions": {
    "standards": [
      {
        "bom-ref": "bsimm-v13",
        "name": "Build Security In Maturity Model (BSIMM)",
        "description": "The BSIMM activities are the individual controls used to construct or improve an SSI. They range through people, process, technology, and culture. You can use this information to choose which controls to apply within your initiative, then align your implementation strategy and metrics with your desired outcomes.",
        "version": "13",
        "owner": "Synopsys, Inc.",
        "requirements": [
          {
            "bom-ref": "governance",
            "title": "Governance",
            "text": "Practices that help organize, manage, and measure a software security initiative. Staff development is also a central governance practice."
          },
          {
            "bom-ref": "intelligence",
            "title": "Intelligence",
            "text": "Practices that result in collections of corporate knowledge used in carrying out software security activities throughout the organization. Collections include both proactive security guidance and organizational threat modeling."
          },
          {
            "bom-ref": "ssdl-touchpoints",
            "title": "SSDL Touchpoints",
            "text": "Practices associated with analysis and assurance of particular software development artifacts and processes. All software security methodologies include these practices."
          },
          {
            "bom-ref": "deployment",
            "title": "Deployment",
            "text": "Practices that interface with traditional network security and software maintenance organizations. Software configuration, maintenance, and other environment issues have direct impact on software security."
          },
          {
            "bom-ref": "governance-sm",
            "title": "Governance: Strategy & Metrics",
            "text": "The Strategy & Metrics practice encompasses planning, assigning roles and responsibilities, identifying software security goals, determining budgets, and identifying metrics and software release conditions.",
            "parent": "governance"
          },
          {
            "bom-ref": "governance-cp",
            "title": "Governance: Compliance & Policy",
            "text": "The Compliance & Policy practice is focused on identifying controls for compliance regimens such as PCI DSS and GDPR, developing contractual controls such as SLAs to help manage COTS software risk, setting organizational software security policy, and auditing against that policy.",
            "parent": "governance"
          },
          {
            "bom-ref": "governance-t",
            "title": "Governance: Training",
            "text": "Training has always played a critical role in software security because organizational stakeholders across GRC, legal, engineering, operations, and other groups often start with little security knowledge.",
            "parent": "governance"
          },
          {
            "bom-ref": "intelligence-am",
            "title": "Intelligence: Attack Models",
            "text": "Attack Models capture information used to think like an attacker, including threat modeling inputs, abuse cases, data classification, and technology-specific attack patterns.",
            "parent": "intelligence"
          },
          {
            "bom-ref": "intelligence-sfd",
            "title": "Intelligence: Security Features & Design",
            "text": "The Security Features & Design practice is charged with creating usable security patterns for major security controls (meeting the standards defined in the Standards & Requirements practice), building components and services for those controls, and establishing collaboration during security design efforts.",
            "parent": "intelligence"
          },
          {
            "bom-ref": "intelligence-sfd",
            "title": "Intelligence: Standards & Requirements",
            "text": "The Standards & Requirements practice involves eliciting explicit software security requirements from the organization, determining which COTS tools to recommend, building standards for major security controls (such as authentication, input validation, and so on), creating security standards for technologies in use, and creating a standards review process.",
            "parent": "intelligence"
          },
          {
            "bom-ref": "ssdl-touchpoints-aa",
            "title": "SSDL Touchpoints: Architecture Analysis",
            "text": "Architecture analysis encompasses capturing software architecture in concise diagrams, applying lists of risks and threats, adopting a process for review (such as Microsoft Threat Modeling [STRIDE] or Architecture Risk Analysis [ARA]), building an assessment and remediation plan for the organization, and using a risk methodology to rank applications.",
            "parent": "ssdl-touchpoints"
          },
          {
            "bom-ref": "ssdl-touchpoints-cr",
            "title": "SSDL Touchpoints: Code Review",
            "text": "The Code Review practice includes use of code review tools (e.g., static analysis), development of tailored rules, customized profiles for tool use by different roles (for example, developers vs. auditors), manual analysis, and tracking and measuring results.",
            "parent": "ssdl-touchpoints"
          },
          {
            "bom-ref": "ssdl-touchpoints-st",
            "title": "SSDL Touchpoints: Security Testing",
            "text": "The Security Testing practice is concerned with prerelease defect discovery, including integrating security into standard QA processes. The practice includes the use of opaque-box application security testing (AST) tools (including fuzz testing) as a smoke test in QA, risk- driven crystal-box test suites, application of the attack model, and code coverage analysis. Security testing focuses on vulnerabilities in construction.",
            "parent": "ssdl-touchpoints"
          },
          {
            "bom-ref": "deployment-pt",
            "title": "Deployment: Penetration Testing",
            "text": "The Penetration Testing practice involves standard outside-in testing of the sort carried out by security specialists. Penetration testing focuses on vulnerabilities in preproduction and production code, providing direct feeds to defect management and mitigation.",
            "parent": "deployment"
          },
          {
            "bom-ref": "deployment-se",
            "title": "Deployment: Software Environment",
            "text": "The Software Environment practice deals with OS and platform patching (including in the cloud), WAFs (web application firewalls), installation and configuration documentation, containerization, orchestration, application monitoring, change management, and code signing.",
            "parent": "deployment"
          },
          {
            "bom-ref": "deployment-cmvm",
            "title": "Deployment: Configuration Management & Vulnerability Management",
            "text": "The Configuration Management & Vulnerability Management practice concerns itself with operations processes, patching and updating applications, version control, defect tracking and remediation, and incident handling.",
            "parent": "deployment"
          },
          {
            "bom-ref": "SM1.1",
            "identifier": "SM1.1",
            "title": "Publish process and evolve as necessary.",
            "text": "The process for addressing software security is defined, published internally, and broadcast to all stakeholders so that everyone knows the plan. Goals, roles, responsibilities, and activities are explicitly defined. Most organizations examine existing methodologies, such as the NIST SSDF, Microsoft SDL, or Synopsys Touchpoints, then tailor them to meet their needs. Security activities will be adapted to software lifecycle processes (e.g., waterfall, Agile, CI/CD, DevOps), so activities will evolve with both the organization and the security landscape. The process doesn't need to be publicly promoted outside the firm to have the desired impact (see [SM3.2]). In addition to publishing the written process, some firms also automate parts (e.g., a testing strategy) as governance-as-code (see [SM3.4]).",
            "parent": "governance-sm"
          },
          {
            "bom-ref": "SM1.3",
            "identifier": "SM1.3",
            "title": "Educate executives on software security.",
            "text": "Executives are regularly shown the ways malicious actors attack software and the negative business impacts those attacks can have on the organization. Go beyond reporting of open and closed defects to educate executives on the business risks, including risks of adopting emerging engineering technologies and methodologies without security oversight. Demonstrate a worst-case scenario in a controlled environment with the permission of all involved (e.g., by showing attacks and their business impact). Presentation to the Board can help garner resources for new or ongoing SSI efforts. Demonstrating the need for new skill-building training in evolving areas, such as DevOps groups using cloud-native technologies, can help convince leadership to accept SSG recommendations when they might otherwise be ignored in favor of faster release dates or other priorities. Bring in an outside expert when necessary to bolster executive attention.",
            "parent": "governance-sm"
          },
          {
            "bom-ref": "SM1.4",
            "identifier": "SM1.4",
            "title": "Implement security checkpoints and associated governance.",
            "text": "The software security process includes checkpoints (such as gates, release conditions, guardrails, milestones, etc.) at one or more points in a software lifecycle. The first two steps toward establishing security-specific checkpoint conditions are to identify process locations that are compatible with existing development practices and to then begin gathering the information necessary to make a go/no-go decision, such as risk-ranking thresholds or defect data. Importantly, the conditions need not be enforced at this stage--for example, the SSG can collect security testing results for each project prior to release, then provide their informed opinion on what constitutes sufficient testing or acceptable test results without trying to stop a project from moving forward (see [SM2.2]). Shorter release cycles might require creative approaches to collecting the right evidence and rely heavily on automation. Socializing the conditions and then enforcing them once most project teams already know how to succeed is a gradual approach that motivates good behavior without introducing unnecessary friction.",
            "parent": "governance-sm"
          },
          {
            "bom-ref": "SM2.1",
            "identifier": "SM2.1",
            "title": "Publish data about software security internally and use it",
            "text": "to drive change. To facilitate improvement, data is published internally about the state of software security within the organization. Produce security or development dashboards with metrics for executives and software development management. Dashboards can be part of pipeline toolchains to enable developer self-improvement. Sometimes, this published data won't be shared with everyone in the firm but only with the stakeholders who are tasked to drive change. In other cases, open book management and data published to all stakeholders helps everyone know what's going on. If the organization's culture promotes internal competition between groups, use this information to add a security dimension. Integrate automated security telemetry to gather measurements quickly and accurately to increase timeliness of security data in areas such as speed (e.g., time to fix) and quality (e.g., defect density). Publishing data about new technologies (e.g., security and risk in cloud-native architectures) is important for identifying needed improvements.",
            "parent": "governance-sm"
          },
          {
            "bom-ref": "SM2.2",
            "identifier": "SM2.2",
            "title": "Enforce security checkpoints and track exceptions.",
            "text": "Enforce security release conditions at each checkpoint (gate, guardrail, milestone, etc.) for every project, so that each project must either meet an established measure or follow a defined process for obtaining an exception to move forward. Use internal policies and standards, regulations, contractual agreements, and other obligations to define release conditions, then track all exceptions. Verifying conditions yields data that informs the KRIs and any other metrics used to govern the process. Automatically giving software a passing grade or granting exceptions without due consideration defeats the purpose of verifying conditions. Even seemingly innocuous software projects (e.g., small code changes, infrastructure access control changes, deployment blueprints) must successfully satisfy the prescribed security conditions as they progress through the software lifecycle. Similarly, APIs, frameworks, libraries, bespoke code, microservices, container configurations, and so on are all software that must satisfy security release conditions. It's possible, and often very useful, to have verified the conditions both before and after the development process itself. In modern development environments, the verification process will increasingly become automated (see [SM3.4]).",
            "parent": "governance-sm"
          },
          {
            "bom-ref": "SM2.3",
            "identifier": "SM2.3",
            "title": "Create or grow a satellite (security champions).",
            "text": "Form a collection of people scattered across the organization--a satellite--who show an above-average level of security interest or skill and who contribute software security expertise to development, QA, and operations teams. Forming this social network of advocates, sometimes referred to as champions, is a good step toward scaling security into software engineering. One way to build the initial group is to track the people who stand out during introductory training courses (see [T3.6]). Another way is to ask for volunteers. In a more top-down approach, initial satellite membership is assigned to ensure good coverage of development groups, but ongoing membership is based on actual performance. The satellite can act as a sounding board for new projects and, in new or fast-moving technology areas, help combine software security skills with domain knowledge that might be under-represented in the SSG or engineering teams. Agile coaches, scrum masters, and DevOps engineers can make particularly useful satellite members, especially for detecting and removing process friction. In some environments, satellite-led efforts are being delivered via automation.",
            "parent": "governance-sm"
          },
          {
            "bom-ref": "SM2.6",
            "identifier": "SM2.6",
            "title": "Require security sign-off prior to software release.",
            "text": "The organization has an initiative-wide process for documenting accountability and accepting security risk by having a risk owner sign off on the state of all software prior to release based on SSG- approved criteria. The sign-off policy might, for example, also require the accountable person to acknowledge critical vulnerabilities that have not been mitigated or SSDL steps that have been skipped. Informal or uninformed risk acceptance alone isn't a security sign-off because the act of accepting risk is more effective when it's formalized (e.g., with a signature, a form submission, or something similar) and captured for future reference. Similarly, simply stating that certain projects don't need sign-off at all won't achieve the desired risk management results. In some cases, however, the risk owner can provide the sign-off on a particular set of software project acceptance criteria, which are then implemented in automation to provide governance-as-code (see [SM3.4]), but there must be an ongoing verification that the criteria remain accurate, and the automation is working.",
            "parent": "governance-sm"
          },
          {
            "bom-ref": "SM2.7",
            "identifier": "SM2.7",
            "title": "Create evangelism role and perform internal marketing.",
            "text": "Build support for software security throughout the organization via ongoing evangelism. This internal marketing function, often performed by a variety of stakeholder roles, keeps executives and others up to date on the magnitude of the software security problem and the elements of its solution. A scrum master familiar with security, for example, could help teams adopt better software security practices as they transform to Agile and DevOps methods. Similarly, a cloud expert could demonstrate the changes needed in security architecture and testing for serverless applications. Evangelists can increase understanding and build credibility by giving talks to internal groups (including executives), publishing roadmaps, authoring technical papers for internal consumption, or creating a collection of papers, books, and other resources on an internal website (see [SR1.2]) and promoting its use. In turn, organizational feedback becomes a useful source of improvement ideas.",
            "parent": "governance-sm"
          },
          {
            "bom-ref": "SM3.1",
            "identifier": "SM3.1",
            "title": "Use a software asset tracking application with portfolio",
            "text": "view. The SSG uses centralized tracking automation to chart the progress of every piece of software and deployable artifact from creation to decommissioning, regardless of development methodology. The automation records the security activities scheduled, in progress, and completed, incorporating results from SSDL activities even when they happen in a tight loop or during deployment. The combined inventory and security posture view enables timely decision-making. The SSG uses the automation to generate portfolio reports for multiple metrics and, in many cases, publishes this data at least among executives. As an initiative matures and activities become more distributed, the SSG uses the centralized reporting system to keep track of all the moving parts.",
            "parent": "governance-sm"
          },
          {
            "bom-ref": "SM3.2",
            "identifier": "SM3.2",
            "title": "Make SSI efforts part of external marketing.",
            "text": "To build external awareness, the SSG helps market the SSI beyond internal teams. In this way, software security can grow its risk reduction exercises into a competitive advantage or market differentiator. The SSG might publish papers or books about its software security capabilities or have a public blog. It might provide details at external conferences or trade shows. In some cases, a complete SSDL methodology can be published and promoted outside the firm, and governance-as-code concepts can make interesting case studies. Regardless of method, the process of sharing details externally and inviting critique is used to bring new perspectives into the firm.",
            "parent": "governance-sm"
          },
          {
            "bom-ref": "SM3.3",
            "identifier": "SM3.3",
            "title": "Identify metrics and use them to drive resourcing.",
            "text": "The SSG and its management identify metrics that define and measure SSI progress in quantitative terms. These metrics are reviewed on a regular basis and drive the initiative's budgeting and resource allocations, so simple counts and out-of-context measurements won't suffice here. On the technical side, one such metric could be defect density, a reduction of which could be used to show a decreasing cost of remediation over time, assuming, of course, that testing depth has kept pace with software changes. Data for metrics is best collected early and often using event-driven processes with telemetry rather than calendar-driven data collection. The key is to tie security results to business objectives in a clear and obvious fashion to justify resourcing. Because the concept of security is already tenuous to many businesspeople, make the tie-in explicit.",
            "parent": "governance-sm"
          },
          {
            "bom-ref": "SM3.4",
            "identifier": "SM3.4",
            "title": "Integrate software-defined lifecycle governance.",
            "text": "Organizations begin replacing traditional document-, presentation-, and spreadsheet-based lifecycle management with software-based delivery platforms. For some software lifecycle phases, humans are no longer the primary drivers of progression from one phase to the next. Instead, organizations rely on automation to drive the management and delivery process with software such as Spinnaker or GitHub, and humans participate asynchronously (and often optionally). Automation often extends beyond the scope of CI/CD to include functional and nonfunctional aspects of delivery, such as health checks, cut-over on failure, rollback to known-good state, defect discovery and management, compliance verification, and a way to ensure adherence to policies and standards. Some organizations are also evolving their lifecycle management approach by integrating their compliance and defect discovery data, perhaps augmented by intelligence feeds and other external data, to begin moving from a series of point-in-time go/no-go decisions (e.g., release conditions) to a future state of continuous accumulation of assurance data (see [CMVM3.6]).",
            "parent": "governance-sm"
          },
          {
            "bom-ref": "SM3.5",
            "identifier": "SM3.5",
            "title": "Integrate software supply chain risk management.",
            "text": "Organizational risk management processes ensure that important software created by and entering the organization is managed through governance-driven access and usage controls, maintenance standards, and captured provenance data. Apply these processes to external (see [SR2.7]), bespoke, and internally developed software, helping to ensure that deployed code has the expected components (see [SE3.8]). The lifecycle management for all software, from creation or importation through secure deployment, ensures that all access, usage, and modifications are done in accordance with policy. This assurance is easier to implement at scale using automation in software lifecycle processes (see [SM3.4]). The Compliance & Policy practice is focused on identifying controls for compliance regimens such as PCI DSS and HIPAA, developing contractual controls such as SLAs to help control COTS software risk, setting organizational software security policy, and auditing against that policy.",
            "parent": "governance-sm"
          },
          {
            "bom-ref": "CP1.1",
            "identifier": "CP1.1",
            "title": "Unify regulatory pressures.",
            "text": "Have a central team to understand the constraints imposed on software security by regulatory or compliance drivers applicable to the organization and its customers. The team creates or collaborates on a unified approach that removes redundancy and conflicts from overlapping compliance requirements, such as from PCI security standards; GLBA, SOX, and HIPAA in the US; or GDPR in the EU. A formal approach will map applicable portions of regulations to controls (see [CP2.3]) applied to software to explain how the organization complies. Existing business processes run by legal, product management, or other risk and compliance groups outside the SSG could serve as the regulatory focal point, with the SSG providing software security knowledge. A unified set of software security guidance for meeting regulatory pressures ensures that compliance work is completed as efficiently as possible.",
            "parent": "governance-cp"
          },
          {
            "bom-ref": "CP1.2",
            "identifier": "CP1.2",
            "title": "Identify privacy obligations.",
            "text": "The SSG identifies privacy obligations stemming from regulation and customer expectations, then translates these obligations into both software requirements and privacy best practices. The way software handles PII might be explicitly regulated, but even if it isn't, privacy is an important topic. For example, if the organization processes credit card transactions, the SSG will help in identifying the constraints that the PCI DSS places on the handling of cardholder data and will inform all stakeholders (see [SR1.3]). Note that outsourcing to hosted environments (e.g., the cloud) doesn't relax privacy obligations and can even increase the difficulty of recognizing and meeting all associated needs. Also note that firms creating software products that process PII when deployed in customer environments might meet this need by providing privacy controls and guidance for their customers. Evolving consumer privacy expectations, the proliferation of \"software is in everything,\" and data scraping and correlation (e.g., social media) add additional expectations for PII protection.",
            "parent": "governance-cp"
          },
          {
            "bom-ref": "CP1.3",
            "identifier": "CP1.3",
            "title": "Create policy.",
            "text": "The SSG guides the organization by creating or contributing to a software security policy that satisfies internal, regulatory, and customer-driven security requirements. This policy is what is permitted and denied at the initiative level--if it's not mandatory and enforced, it's not policy. It includes a unified approach for satisfying the (potentially lengthy) list of security drivers at the governance level so project teams can avoid keeping up with the details involved in complying with all applicable regulations or other mandates. Likewise, project teams won't need to relearn customer security requirements on their own. Architecture standards and coding guidelines aren't examples of policy, but policy that prescribes and mandates their use for certain software categories falls under that umbrella. In many cases, policy statements are translated into automation to provide governance-as-code. Even if not enforced by humans, policy that's been automated must still be mandatory. In some cases, policy will be documented exclusively as governance- as-code (see [SM3.4]), often as tool configuration, but it must still be readily readable, auditable, and editable by humans.",
            "parent": "governance-cp"
          },
          {
            "bom-ref": "CP2.1",
            "identifier": "CP2.1",
            "title": "Build PII inventory.",
            "text": "The organization identifies and tracks the kinds of PII processed or stored by each of its systems, along with their associated data repositories. In general, simply noting which applications process PII isn't enough--the type of PII (e.g., PHI, PFI, PI, etc.) and where it is stored are necessary so the inventory can be easily referenced in critical situations. This usually includes making a list of databases that would require customer notification if breached or a list to use in crisis simulations (see [CMVM3.3]). Build the PII inventory by starting with each individual application and noting its PII use, or by starting with PII types and noting the applications that touch each type. System architectures have evolved such that PII will flow into cloud-based service and endpoint device ecosystems, then come to rest there (e.g., content delivery networks, social networks, mobile devices, IoT devices), making it tricky to keep an accurate PII inventory.",
            "parent": "governance-cp"
          },
          {
            "bom-ref": "CP2.2",
            "identifier": "CP2.2",
            "title": "Require security sign-off for compliance-related risk.",
            "text": "The organization has a formal compliance risk acceptance sign-off and accountability process that addresses all software development projects. In this process, the SSG acts as an advisor while the risk owner signs off on the software's compliance state prior to release based on its adherence to documented criteria. The sign-off policy might also require the head of the business unit to acknowledge compliance issues that haven't been mitigated or compliance-related SSDL steps that have been skipped, but it is required even when no compliance-related risk is present. Sign-off is explicit and captured for future reference, with any exceptions tracked, even in automated application lifecycle methodologies. Note that an application without security defects might still be noncompliant, so clean security testing results are not a substitute for a compliance sign-off. Even in DevOps organizations where engineers have the technical ability to release software, there is still a need for a deliberate risk acceptance step even if the compliance criteria are embedded in automation (see [SM3.4]). In cases where the risk owner signs off on a particular set of compliance acceptance criteria that are then implemented in automation to provide governance-as-code, there must be ongoing verification that the criteria remain accurate, and the automation is actually working.",
            "parent": "governance-cp"
          },
          {
            "bom-ref": "CP2.3",
            "identifier": "CP2.3",
            "title": "Implement and track controls for compliance.",
            "text": "The organization can demonstrate compliance with applicable requirements because its SSDL is aligned with the control statements developed by the SSG in collaboration with compliance stakeholders (see [CP1.1]). The SSG collaborates with stakeholders to track controls, navigate problem areas, and ensure that auditors and regulators are satisfied. The SSG can remain in the background when the act of following the SSDL automatically generates the desired compliance evidence predictably and reliably. Increasingly, the DevOps approach embeds compliance controls in automation, such as in software-defined infrastructure and networks, rather than in human process and manual intervention. A firm doing this properly can explicitly associate satisfying its compliance concerns with following its SSDL.",
            "parent": "governance-cp"
          },
          {
            "bom-ref": "CP2.4",
            "identifier": "CP2.4",
            "title": "Include software security SLAs in all vendor contracts.",
            "text": "Software vendor contracts include an SLA to ensure that the vendor's security efforts align with the organization's compliance story. Each new or renewed contract contains provisions requiring the vendor to address software security and deliver a product or service compatible with the organization's security policy. In some cases, open source licensing concerns initiate the vendor management process, which can open the door for additional software security language in the SLA (see [SR2.5]). Typical provisions set requirements for policy conformance, incident management, training, defect management, and response times for addressing software security issues. Traditional IT security requirements and a simple agreement to allow penetration testing or another defect discovery activity aren't sufficient here.",
            "parent": "governance-cp"
          },
          {
            "bom-ref": "CP2.5",
            "identifier": "CP2.5",
            "title": "Ensure executive awareness of compliance and privacy",
            "text": "obligations. Gain buy-in around compliance and privacy activities by providing executives with plain-language explanations of the organization's compliance and privacy obligations, along with the potential consequences of failing to meet those obligations. For some organizations, explaining the direct cost and likely fallout from a compliance failure or data breach can be an effective way to broach the subject. For others, having an outside expert address the Board works because some executives value an outside perspective more than an internal one. A sure sign of proper executive buy-in is an acknowledgment of the need along with adequate allocation of resources to meet those obligations. Use the sense of urgency that typically follows a compliance or privacy failure to build additional awareness and bootstrap new efforts.",
            "parent": "governance-cp"
          },
          {
            "bom-ref": "CP3.1",
            "identifier": "CP3.1",
            "title": "Document a software compliance story.",
            "text": "The SSG can demonstrate the organization's software security compliance story on demand using a combination of written policy, controls documentation, and artifacts gathered through the SSDL. Often, senior management, auditors, and regulators--whether government or other--will be satisfied with the same kinds of reports that can be generated directly from various tools. In some cases, particularly where organizations leverage shared responsibility through cloud services, the organization will require additional information from vendors about how that vendor's controls support organizational compliance needs. It will often be necessary to normalize information that comes from disparate sources.",
            "parent": "governance-cp"
          },
          {
            "bom-ref": "CP3.2",
            "identifier": "CP3.2",
            "title": "Ensure compatible vendor policies.",
            "text": "Ensure that vendor software security policies and SSDL processes are compatible with internal policies. Vendors likely comprise a diverse group--cloud providers, middleware providers, virtualization providers, container and orchestration providers, bespoke software creators, contractors, and many more--and each might be held to different policy requirements. Policy adherence enforcement might be through a point-in-time review (such as ensuring acceptance criteria), automated checks (such as those applied to pull requests, committed artifacts like containers, or similar), or convention and protocol (such as preventing services connection unless security settings are correct and expected certificates are present). Evidence of vendor adherence could include results from SSDL activities, from manual tests or tests built directly into automation or infrastructure, or from other software lifecycle instrumentation. For some policies or SSDL processes, vendor questionnaire responses and attestation alone might be sufficient.",
            "parent": "governance-cp"
          },
          {
            "bom-ref": "CP3.3",
            "identifier": "CP3.3",
            "title": "Drive feedback from software lifecycle data back to policy.",
            "text": "Feed information from the software lifecycle into the policy creation and maintenance process to drive improvements, such as defect prevention and strengthening governance-as-code practices (see [SM3.4]). With this feedback as a routine process, blind spots can be eliminated by mapping them to trends in SSDL failures. Events such as the regular appearance of inadequate architecture analysis, recurring vulnerabilities, ignored security release conditions, or the wrong vendor choice for carrying out a penetration test can expose policy weakness (see [CP1.3]). As an example, lifecycle data might indicate that policies impose too much bureaucracy by introducing friction that prevents engineering from meeting the expected delivery cadence. Rapid technology evolution might also create policy gaps that must be addressed. Over time, policies become more practical and easier to carry out (see [SM1.1]). Ultimately, policies are refined with SSDL data to enhance and improve a firm's effectiveness.",
            "parent": "governance-cp"
          },
          {
            "bom-ref": "T1.1",
            "identifier": "T1.1",
            "title": "Conduct software security awareness training.",
            "text": "To promote a culture of software security throughout the organization, the SSG conducts periodic software security awareness training. This training might be delivered via SSG members, an outside firm, the internal training organization, or e-learning, but course content isn't necessarily tailored for a specific audience-- developers, QA engineers, and project managers could attend the same \"Introduction to Software Security\" course, for example. Augment this content with a tailored approach that addresses the firm's culture explicitly, which might include the process for building security in, avoiding common mistakes, and technology topics such as CI/CD and DevSecOps. Generic introductory courses that cover basic IT or high-level security concepts don't generate satisfactory results. Likewise, awareness training aimed only at developers and not at other roles in the organization is insufficient.",
            "parent": "governance-t"
          },
          {
            "bom-ref": "T1.7",
            "identifier": "T1.7",
            "title": "Deliver on-demand individual training.",
            "text": "The organization lowers the burden on students and reduces the cost of delivering software security training by offering on-demand training for SSDL stakeholders. The most obvious choice, e-learning, can be kept up to date through a subscription model, but an online curriculum must be engaging and relevant to students in various roles (e.g., developer, QA, cloud, ops, etc.) to achieve its intended purpose. Ineffective (e.g., aged, off-topic) training or training that isn't used won't create any change. Hot topics like containerization and security orchestration, and new delivery styles such as gamification, will attract more interest than boring policy discussions. For developers, it's possible to provide training directly through the IDE right when it's needed, but in some cases, building a new skill (such as cloud security or threat modeling) might be better suited for instructor-led training, which can also be provided on demand.",
            "parent": "governance-t"
          },
          {
            "bom-ref": "T1.8",
            "identifier": "T1.8",
            "title": "Include security resources in onboarding.",
            "text": "The process for bringing new hires into a software engineering organization requires timely completion of a training module about software security. While the generic new hire process usually covers topics like picking a good password and avoiding phishing, this orientation period is enhanced to cover topics such as how to create, deploy, and operate secure code, the SSDL, security standards (see [SR1.1]), and internal security resources (see [SR1.2]). The objective is to ensure that new hires contribute to the security culture as soon as possible. Although a generic onboarding module is useful, it doesn't take the place of a timely and more complete introductory software security course.",
            "parent": "governance-t"
          },
          {
            "bom-ref": "T2.5",
            "identifier": "T2.5",
            "title": "Enhance satellite (security champions) through training and",
            "text": "events. Strengthen the satellite network (see [SM2.3]) by inviting guest speakers or holding special events about advanced software security topics. This effort is about providing to the satellite customized training (e.g., the latest software security techniques for DevOps or serverless technologies, or on the implications of new policies and standards) so that it can fulfill its assigned responsibilities--it's not about inviting satellite members to routine brown bags or signing them up for standard computer-based training. Similarly, a standing conference call with voluntary attendance won't get the desired results, which are as much about building camaraderie as they are about sharing knowledge and organizational efficiency. Regular events build community and facilitate collaboration and collective problem-solving. Face-to-face meetings are by far the most effective, even if they happen only once or twice a year and even if some participants must attend by videoconferencing. In teams with many geographically dispersed and work-from-home members, simply turning on cameras and ensuring that everyone gets a chance to speak makes a substantial difference.",
            "parent": "governance-t"
          },
          {
            "bom-ref": "T2.8",
            "identifier": "T2.8",
            "title": "Create and use material specific to company history.",
            "text": "To make a strong and lasting change in behavior, training includes material specific to the company's history of software security challenges. When participants can see themselves in a problem, they're more likely to understand how the material is relevant to their work as well as when and how to apply what they've learned. One way to do this is to use noteworthy attacks on the company's software as examples in the training curriculum. Both successful and unsuccessful attacks, as well as notable results from penetration tests and red team exercises, can make good teachable moments. Stories from company history can help steer training in the right direction, but only if those stories are still relevant and not overly censored. This training should cover platforms used by developers (developers orchestrating containers probably won't care about old virtualization problems) and problems relevant to languages in common use.",
            "parent": "governance-t"
          },
          {
            "bom-ref": "T2.9",
            "identifier": "T2.9",
            "title": "Deliver role-specific advanced curriculum.",
            "text": "Software security training goes beyond building awareness (see [T1.1]) by enabling students to incorporate security practices into their work. This training is tailored to cover the tools, technology stacks, development methodologies, and issues that are most relevant to students. An organization could offer tracks for its engineers, for example, one each for architects, developers, operations, DevOps, site reliability engineers, and testers. Tool- specific training is also commonly needed in such a curriculum. While it might be more concise than engineering training, role- specific training is also necessary for many stakeholders within an organization, including product management, executives, and others. In any case, the training must be taken by a broad enough audience to build the collective skillsets required.",
            "parent": "governance-t"
          },
          {
            "bom-ref": "T2.10",
            "identifier": "T2.10",
            "title": "Host software security events.",
            "text": "The organization hosts security events featuring external speakers and content in order to strengthen its security culture. Good examples of such events are Intel iSecCon and AWS re:Inforce, which invite all employees, feature external presenters, and focus on helping engineering create, deploy, and operate better code. Employees benefit from hearing outside perspectives, especially those related to fast-moving technology areas with software security ramifications, and the organization benefits from putting its security credentials on display (see [SM3.2]). Events open only to small, select groups, or simply putting recordings on an internal portal, won't result in the desired culture change across the organization.",
            "parent": "governance-t"
          },
          {
            "bom-ref": "T2.11",
            "identifier": "T2.11",
            "title": "Require an annual refresher.",
            "text": "Everyone involved in the SSDL is required to take an annual software security refresher course. This course keeps the staff up to date on the organization's security approach and ensures that the organization doesn't lose focus due to turnover, evolving methodologies, or changing deployment models. The SSG might give an update on the security landscape and explain changes to policies and standards. A refresher could also be rolled out as part of a firm- wide security day or in concert with an internal security conference. Coverage of new topics and changes to the previous year's content should result in a significant amount of fresh content.",
            "parent": "governance-t"
          },
          {
            "bom-ref": "T3.1",
            "identifier": "T3.1",
            "title": "Reward progression through curriculum.",
            "text": "Progression through the security curriculum brings personal benefits, such as public acknowledgement or career advancement. The reward system can be formal and lead to a certification or an official mark in the human resources system, or it can be less formal and include motivators such as documented praise at annual review time. Involving a corporate training department and human resources team can make the impact of improving security skills on career progression more obvious, but the SSG should continue to monitor security knowledge in the firm and not cede complete control or oversight. Coffee mugs and t-shirts can build morale, but it usually takes the possibility of real career progression to change behavior.",
            "parent": "governance-t"
          },
          {
            "bom-ref": "T3.2",
            "identifier": "T3.2",
            "title": "Provide training for vendors and outsourced workers.",
            "text": "Vendors and outsourced workers receive the same level of software security training given to employees. Spending time and effort helping suppliers get security right at the outset is much easier than trying to determine what went wrong later, especially if the development team has moved on to other projects. Training individual contractors is much more natural than training entire outsourced firms and is a reasonable place to start. It's important that everyone who works on the firm's software has an appropriate level of training that increases their capability of meeting the software security expectations for their role, regardless of their employment status. Of course, some vendors and outsourced workers might have received adequate training from their own firms, but that should always be verified.",
            "parent": "governance-t"
          },
          {
            "bom-ref": "T3.5",
            "identifier": "T3.5",
            "title": "Provide expertise via open collaboration channels.",
            "text": "Software security experts offer help to anyone in an open manner during regularly scheduled office hours or openly accessible channels on Slack, Jira, or similar. By acting as an informal resource for people who want to solve security problems, the SSG leverages teachable moments and emphasizes the carrot over the stick approach to security best practices. Office hours might be hosted one afternoon per week by a senior SSG member, perhaps inviting briefings from product or application groups working on hard security problems. Slack and other messaging applications can capture questions 24x7, functioning as an office hours platform when appropriate subject matter experts are consistently part of the conversation and are ensuring that the answers generated align with SSG expectations. An online approach has the added benefit of discussions being recorded and searchable.",
            "parent": "governance-t"
          },
          {
            "bom-ref": "T3.6",
            "identifier": "T3.6",
            "title": "Identify new satellite members (security champions) through",
            "text": "observation. Future satellite members (e.g., security champions) are recruited by noting people who stand out during training courses, office hours, capture-the-flag exercises, hack-a-thons, and other opportunities that show skill and enthusiasm, then encouraging them to join the satellite. Pay particular attention to practitioners who are contributing things such as code, security configurations, or defect discovery rules. The satellite often begins as an assigned collection of people scattered across the organization who show an above-average level of security interest or advanced knowledge of new technology stacks and development methodologies (see [SM2.3]). Identifying future members proactively is a step toward creating a social network that speeds the adoption of security into software development and operations. A group of enthusiastic and skilled volunteers will be easier to lead than a group that is drafted.",
            "parent": "governance-t"
          },
          {
            "bom-ref": "AM1.2",
            "identifier": "AM1.2",
            "title": "Use a data classification scheme for software inventory.",
            "text": "Security stakeholders in an organization agree on a data classification scheme and use it to inventory software, delivery artifacts (e.g., containers), and associated persistent data stores according to the kinds of data processed or services called, regardless of deployment model (e.g., on- or off-premises). Many classification schemes are possible--one approach is to focus on PII, for example. Depending on the scheme and the software involved, it could be easiest to first classify data repositories (see [CP2.1]), then derive classifications for applications according to the repositories they use. Other approaches include data classification according to protection of intellectual property, impact of disclosure, exposure to attack, relevance to GDPR, and geographic boundaries.",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "AM1.3",
            "identifier": "AM1.3",
            "title": "Identify potential attackers.",
            "text": "The SSG identifies potential attackers in order to understand their motivations and abilities. The outcome of this periodic exercise could be a set of attacker profiles that includes outlines for categories of attackers and more detailed descriptions for noteworthy individuals that are used in end-to-end design review (see [AA1.2]). In some cases, a third-party vendor might be contracted to provide this information. Specific and contextual attacker information is almost always more useful than generic information copied from someone else's list. Moreover, a list that simply divides the world into insiders and outsiders won't drive useful results. Identification of attackers should also consider the organization's evolving software supply chain, attack surface, theoretical internal attackers, and contract staff.",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "AM1.5",
            "identifier": "AM1.5",
            "title": "Gather and use attack intelligence.",
            "text": "The SSG ensures the organization stays ahead of the curve by learning about new types of attacks and vulnerabilities, then adapts that information to the organization's needs. Attack intelligence must be made actionable and useful for a variety of consumers, which might include developers, testers, DevOps, security operations, and reliability engineers, among others. In many cases, a subscription to a commercial service can provide a reasonable way of gathering basic attack intelligence related to applications, APIs, containerization, orchestration, cloud environments, and so on. Attending technical conferences and monitoring attacker forums, then correlating that information with what's happening in the organization (perhaps by leveraging automation to mine operational logs and telemetry) helps the SSG learn more about emerging vulnerability exploitation.",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "AM2.1",
            "identifier": "AM2.1",
            "title": "Build attack patterns and abuse cases tied to potential",
            "text": "attackers. The SSG works with stakeholders to build attack patterns and abuse cases tied to potential attackers (see [AM1.3]). These resources can be built from scratch or from standard sets, such as the MITRE ATT&CK framework, and the SSG adds to the pile based on its own attack stories to prepare the organization for SSDL activities such as design review and penetration testing. For example, a story about an attack against a poorly designed cloud-native application could lead to a containerization attack pattern that drives a new type of testing (see [ST3.5]). If a firm tracks the fraud and monetary costs associated with specific attacks, this information can in turn be used to prioritize the process of building attack patterns and abuse cases. Organizations will likely need to evolve their attack pattern and abuse case creation prioritization and content over time due to changing software architectures (e.g., zero trust, cloud-native, serverless), attackers, and technologies.",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "AM2.2",
            "identifier": "AM2.2",
            "title": "Create technology-specific attack patterns.",
            "text": "The SSG facilitates technology-specific attack pattern creation by collecting and providing knowledge about attacks relevant to the organization's technologies. For example, if the organization's cloud software relies on a cloud vendor's security apparatus (e.g., key and secrets management), the SSG can help catalog the quirks of the crypto package and how it might be exploited. Attack patterns directly related to the security frontier (e.g., serverless) can be useful here as well. It's often easiest to start with existing generalized attack patterns to create the needed technology-specific ones, but simply adding \"for microservices\" at the end of a generalized pattern name, for example, won't suffice.",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "AM2.5",
            "identifier": "AM2.5",
            "title": "Maintain and use a top N possible attacks list.",
            "text": "The SSG periodically digests the ever-growing list of attack types, creates a prioritized short list--the top N--and then uses the list to drive change. This initial list almost always combines input from multiple sources, both inside and outside the organization. Some organizations prioritize their list according to a perception of potential business loss while others might prioritize according to preventing successful attacks against their software. The top N list doesn't need to be updated with great frequency, and attacks can be coarsely sorted. For example, the SSG might brainstorm twice a year to create lists of attacks the organization should be prepared to counter \"now,\" \"soon,\" and \"someday.\"",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "AM2.6",
            "identifier": "AM2.6",
            "title": "Collect and publish attack stories.",
            "text": "To maximize the benefit from lessons that don't always come cheap, the SSG collects and publishes stories about attacks against the organization's software. Both successful and unsuccessful attacks can be noteworthy, and discussing historical information about software attacks has the added effect of grounding software security in a firm's reality. This is particularly useful in training classes (see [T2.8]) to help counter a generic approach that might be overly focused on other organizations' most common bug lists or outdated platform attacks. Hiding or overly sanitizing information about attacks from people building new systems fails to garner any positive benefits from a negative event.",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "AM2.7",
            "identifier": "AM2.7",
            "title": "Build an internal forum to discuss attacks.",
            "text": "The organization has an internal, interactive forum where the SSG, the satellite, incident response, and others discuss attacks and attack methods. The discussion serves to communicate the attacker perspective to everyone. It's useful to include all successful attacks here, regardless of attack source, such as supply chain, internal, consultants, or bug bounty contributors. The SSG augments the forum with an internal communications channel (see [T3.5]) that encourages subscribers to discuss the latest information on publicly known incidents. Dissection of attacks and exploits that are relevant to a firm are particularly helpful when they spur discussion of development, infrastructure, and other mitigations. Simply republishing items from public mailing lists doesn't achieve the same benefits as active and ongoing discussions, nor does a closed discussion hidden from those creating code and configurations. Everyone should feel free to ask questions and learn about vulnerabilities and exploits.",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "AM3.1",
            "identifier": "AM3.1",
            "title": "Have a research group that develops new attack methods.",
            "text": "A research group works to identify and mitigate the impact of new classes of attacks and shares their knowledge with stakeholders. Identification does not always require original research--the group might expand on an idea discovered by others. Doing this research in- house is especially important for early adopters of new technologies and configurations so that they can discover potential weaknesses before attackers do. One approach is to create new attack methods that simulate persistent attackers during goal-oriented red team exercises (see [PT3.1]). This isn't a penetration testing team finding new instances of known types of weaknesses, it's a research group that innovates attack methods and mitigation approaches. Example mitigation approaches include test cases, static analysis rules, attack patterns, standards, and policy changes. Some firms provide researchers time to follow through on their discoveries by using bug bounty programs or other means of coordinated disclosure (see [CMVM3.7]). Others allow researchers to publish their findings at conferences like DEF CON to benefit everyone.",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "AM3.2",
            "identifier": "AM3.2",
            "title": "Create and use automation to mimic attackers.",
            "text": "The SSG arms engineers, testers, and incident response with automation to mimic what attackers are going to do. For example, a new attack method identified by an internal research group (see [AM3.1]) or a disclosing third party could require a new tool, so the SSG could package the tool and distribute it to testers. The idea here is to push attack capability past what typical commercial tools and offerings encompass, then make that knowledge and technology easy for others to use. Mimicking attackers, and especially attack chains, almost always requires tailoring tools to a firm's particular technology stacks, infrastructure, and configurations. When technology stacks and coding languages evolve faster than vendors can innovate, creating tools and automation in-house might be the best way forward. In the DevOps world, these tools might be created by engineering and embedded directly into toolchains and automation (see [ST3.6]).",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "AM3.3",
            "identifier": "AM3.3",
            "title": "Monitor automated asset creation.",
            "text": "Implement technology controls that provide a continuously updated view of the various network, machine, software, and related infrastructure assets being instantiated by engineering teams. To help ensure proper coverage, the SSG works with engineering teams (including potential shadow IT teams) to understand orchestration, cloud configuration, and other self-service means of software delivery to ensure proper monitoring. This monitoring requires a specialized effort--normal system, network, and application logging and analysis won't suffice. Success might require a multi-pronged approach, including consuming orchestration and virtualization metadata, querying cloud service provider APIs, and outside-in web crawling and scraping.",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "SFD1.1",
            "identifier": "SFD1.1",
            "title": "Integrate and deliver security features.",
            "text": "Provide proactive guidance on preapproved security features for engineering groups to use rather than each group implementing its own security features. Engineering groups benefit from implementations that come preapproved, and the SSG benefits by not having to repeatedly track down the kinds of subtle errors that often creep into security features (e.g., authentication, role management, key management, logging, cryptography, protocols). These features might be discovered during SSDL activities, created by the SSG or specialized development teams, or defined in configuration templates (e.g., cloud blueprints) and delivered via mechanisms such as containers, microservices, and APIs. Generic security features often must be tailored for specific platforms. For example, each mobile and cloud platform will likely need its own means by which users are authenticated and authorized, secrets are managed, and user actions are centrally logged and monitored. It's implementing these defined security features that generates real progress, not simply making a list of them.",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "SFD1.2",
            "identifier": "SFD1.2",
            "title": "Application architecture teams engage with the SSG.",
            "text": "Application architecture teams take responsibility for security in the same way they take responsibility for performance, availability, scalability, and resiliency. One way to keep security from falling out of these architecture discussions is to have secure design experts (from the SSG, a vendor, etc.) participate. Increasingly, architecture discussions include developers and site reliability engineers who are governing all types of software components, such as open source, APIs, containers, and cloud services. In other cases, enterprise architecture teams have the knowledge to help the experts create secure designs that integrate properly into corporate design standards. Proactive engagement with experts is key to success here. In addition, it's never safe for one team to assume another team has addressed security requirements--even moving a well-known system to the cloud means reengaging the experts.",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "SFD2.1",
            "identifier": "SFD2.1",
            "title": "Leverage secure-by-design components and services.",
            "text": "Build or provide approved secure-by-design software components and services for use by engineering teams. Prior to approving and publishing secure-by-design software components and services, including open source and cloud services, the SSG must carefully assess them for security. This assessment process to declare a component secure-by-design is usually more rigorous and in-depth than that for typical projects. In addition to teaching by example, these resilient and reusable building blocks aid important efforts such as architecture analysis and code review by making it easier to avoid mistakes. These components and services also often have features (e.g., application identity, RBAC) that enable uniform usage across disparate environments. Similarly, the SSG might further take advantage of this defined list by tailoring static analysis rules specifically for the components it offers (see [CR2.6]).",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "SFD2.2",
            "identifier": "SFD2.2",
            "title": "Create capability to solve difficult design problems.",
            "text": "Contribute to building resilient architectures by solving design problems unaddressed by organizational security components or services, or by cloud service providers, thus minimizing the negative impact that security has on other constraints, such as feature velocity. Involving the SSG and secure design experts in application refactoring or in the design of a new protocol, microservice, or architecture decision (e.g., containerization) enables timely analysis of the security implications of existing defenses and identifies elements to be improved. Designing for security early in the new project process is more efficient than analyzing an existing design for security and then refactoring when flaws are uncovered (see [AA1.1], [AA1.2], [AA2.1]). The SSG could also get involved in what would have historically been purely engineering discussions, as even rudimentary use of cloud-native technologies (e.g., \"Hello, world!\") requires proper use of configurations and other capabilities that have direct implications on security posture.",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "SFD3.1",
            "identifier": "SFD3.1",
            "title": "Form a review board to approve and maintain secure design",
            "text": "patterns. A review board formalizes the process of reaching and maintaining consensus on security tradeoffs in design needs. Unlike a typical architecture committee focused on functions, this group focuses on providing security guidance, often in the form of patterns, standards, features, or frameworks. It also periodically reviews already published design guidance (especially around authentication, authorization, and cryptography) to ensure that design decisions don't become stale or out of date. This review board helps control the chaos associated with adoption of new technologies when development groups might otherwise make decisions on their own without engaging the SSG. Review board security guidance can also serve to inform outsourced software providers about security expectations (see [CP3.2]).",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "SFD3.2",
            "identifier": "SFD3.2",
            "title": "Require use of approved security features and frameworks.",
            "text": "Implementers must take their security features and frameworks from an approved list or repository (see [SFD1.1], [SFD2.1], [SFD3.1]). There are two benefits to this activity--developers don't spend time reinventing existing capabilities, and review teams don't have to contend with finding the same old defects in new projects or when new platforms are adopted. Reusing proven components eases testing, code review, and threat modeling (see [AA1.1]). Reuse is a major advantage of consistent software architecture and is particularly helpful for Agile development and velocity maintenance in CI/CD pipelines. Packaging and applying required components, such as via containerization (see [SE2.5]), makes it especially easy to reuse approved features and frameworks.",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "SFD3.3",
            "identifier": "SFD3.3",
            "title": "Find and publish secure design patterns from the",
            "text": "organization. Foster centralized design reuse by collecting secure design patterns (sometimes referred to as security blueprints) from across the organization and publishing them for everyone to use. A section of the SSG website (see [SR1.2]) could promote positive elements identified during threat modeling or architecture analysis so that good ideas spread widely. This process is formalized--an adhoc, accidental noticing isn't sufficient. Common design patterns accelerate development, so it's important to use secure design patterns, not just for applications but for all software assets (e.g., microservices, APIs, containers, infrastructure, and automation).",
            "parent": "intelligence-am"
          },
          {
            "bom-ref": "SR1.1",
            "identifier": "SR1.1",
            "title": "Create security standards.",
            "text": "The organization meets the demand for security guidance by creating standards that explain the required way to adhere to policy and carry out security-centric design, development, and operations. A standard might describe how to perform identity-based application authentication or how to implement transport-level security, perhaps with the SSG ensuring the availability of a reference implementation. Standards often apply to software beyond the scope of an application's code, including container construction, orchestration, infrastructure-as-code, and cloud security configuration. Standards can be deployed in a variety of ways to keep them actionable and relevant. They can be automated into development environments (such as an IDE or toolchain) or explicitly linked to code examples and deployment artifacts (e.g., containers). In any case, to be considered standards, they must be adopted and enforced.",
            "parent": "intelligence-sr"
          },
          {
            "bom-ref": "SR1.2",
            "identifier": "SR1.2",
            "title": "Create a security portal.",
            "text": "The organization has a well-known central location for information about software security. Typically, this is an internal website maintained by the SSG and satellite (security champions) that people refer to for current information on security policies, standards, and requirements, as well as for other resources (such as training). An interactive portal is better than a static portal with guideline documents that rarely change. Organizations often supplement these materials with mailing lists, chat channels (see [T3.5]), and face-to- face meetings. Development teams are increasingly putting software security knowledge directly into toolchains and automation that are outside the organization (e.g., GitHub), but that does not remove the need for SSG-led knowledge management.",
            "parent": "intelligence-sr"
          },
          {
            "bom-ref": "SR1.3",
            "identifier": "SR1.3",
            "title": "Translate compliance constraints to requirements.",
            "text": "Compliance constraints are translated into security requirements for individual projects and communicated to the engineering teams. This is a linchpin in the organization's compliance strategy--by representing compliance constraints explicitly with requirements and informing stakeholders, the organization demonstrates that compliance is a manageable task. For example, if the organization builds software that processes credit card transactions, PCI DSS compliance plays a role during the security requirements phase. In other cases, technology standards built for international interoperability can include security guidance on compliance needs. Representing these standards as requirements also helps with traceability and visibility in the event of an audit. It's particularly useful to codify the requirements into reusable code (see [SFD2.1]) or artifact deployment specifications (see [SE2.2]).",
            "parent": "intelligence-sr"
          },
          {
            "bom-ref": "SR2.2",
            "identifier": "SR2.2",
            "title": "Create a standards review process.",
            "text": "Create a process to develop software security standards and ensure that all stakeholders have a chance to weigh in. This review process could operate by appointing a spokesperson for any proposed security standard, putting the onus on the person to demonstrate that the standard meets its goals and to get buy-in and approval from stakeholders. Enterprise architecture or enterprise risk groups sometimes take on the responsibility of creating and managing standards review processes. When the standards are implemented directly as software, the responsible person might be a DevOps manager, release engineer, or whoever owns the associated deployment artifact (e.g., the orchestration code).",
            "parent": "intelligence-sr"
          },
          {
            "bom-ref": "SR2.4",
            "identifier": "SR2.4",
            "title": "Identify open source.",
            "text": "Identify open source components and dependencies included in the organization's code repositories and built software, then review them to understand their security posture. Organizations use a variety of tools and metadata provided by delivery pipelines to discover old versions of open source components with known vulnerabilities or that their software relies on multiple versions of the same component. Scale efforts by using automated tools to find open source, whether whole components or perhaps large chunks of borrowed code. Some software development pipeline platforms, container registries, and middleware platforms have begun to provide this visibility as metadata (e.g., SBOMs, [SE3.6]) resulting from behind-the-scenes artifact scanning. Some organizations combine composition analysis results from multiple phases of the software lifecycle to get a more complete and accurate list of the open source being included in production software.",
            "parent": "intelligence-sr"
          },
          {
            "bom-ref": "SR2.5",
            "identifier": "SR2.5",
            "title": "Create SLA boilerplate.",
            "text": "The SSG works with the legal department to create standard SLA boilerplate for use in contracts with vendors and outsource providers, including cloud providers, to require software security efforts on their part. The legal department might also leverage the boilerplate to help prevent compliance and privacy problems. Under the agreement, vendors and outsource providers must meet company-mandated software security SLAs (see [CP2.4]). Boilerplate language might call for objective third-party insight into software security efforts, such as BSIMMsc measurements or BSIMM scores.",
            "parent": "intelligence-sr"
          },
          {
            "bom-ref": "SR2.7",
            "identifier": "SR2.7",
            "title": "Control open source risk.",
            "text": "The organization has control over its exposure to the risks that come along with using open source components and all the involved dependencies, including dependencies integrated at runtime. Controlling exposure usually includes multiple efforts, with one example being responding to known vulnerabilities in identified open source (see [SR2.4]). The use of open source could also be restricted to predefined projects or to a short list of versions that have been through an approved security screening process, have had unacceptable vulnerabilities remediated, and are made available only through approved internal repositories and containers. For some use cases, policy might preclude any use of open source. The legal department often spearheads additional open source controls due to the viral license problem associated with GPL code. SSGs that partner with and educate the legal department can help move an organization to improve its open source risk management practices, which must be applied across the software portfolio to be effective.",
            "parent": "intelligence-sr"
          },
          {
            "bom-ref": "SR3.2",
            "identifier": "SR3.2",
            "title": "Communicate standards to vendors.",
            "text": "Work with vendors to educate them and promote the organization's security standards. A healthy relationship with a vendor isn't guaranteed through contract language alone (see [CP2.4]), so the SSG should engage with vendors, discuss vendor security practices, and explain in simple terms (rather than legalese) what the organization expects. Any time a vendor adopts the organization's security standards, it's a clear sign of progress. Note that standards implemented as security features or infrastructure configuration could be a requirement to services integration with a vendor (see [SFD1.1], [SE2.2]). When the firm's SSDL is publicly available, communication regarding software security expectations is easier. Likewise, sharing internal practices and measures can make expectations clear.",
            "parent": "intelligence-sr"
          },
          {
            "bom-ref": "SR3.3",
            "identifier": "SR3.3",
            "title": "Use secure coding standards.",
            "text": "Developers use secure coding standards to avoid the most obvious bugs and as ground rules for code review. These standards are necessarily specific to a programming language, and they can address the use of popular frameworks, APIs, libraries, and infrastructure automation. Secure coding standards can also be for low- or no-code platforms (e.g., Microsoft Power Apps, Salesforce Lightning). While enforcement isn't the point at this stage (see [CR3.5]), violation of standards is a teachable moment for all stakeholders. Other useful coding standards topics include proper use of cloud APIs, use of approved cryptography, memory sanitization, banned functions, open source use, and many others. If the organization already has coding standards for other purposes, its secure coding standards should build upon them. A clear set of secure coding standards is a good way to guide both manual and automated code review, as well as to provide relevant examples for security training. Some groups might choose to integrate their secure coding standards directly into automation. Socializing the benefits of following standards is also a good first step to gaining widespread acceptance (see [SM2.7]).",
            "parent": "intelligence-sr"
          },
          {
            "bom-ref": "SR3.4",
            "identifier": "SR3.4",
            "title": "Create standards for technology stacks.",
            "text": "The organization standardizes on the use of specific technology stacks. This translates into a reduced workload because teams don't have to explore new technology risks for every new project. The organization might create a secure base configuration (commonly in the form of golden images, Terraform definitions, etc.) for each technology stack, further reducing the amount of work required to use the stack safely. In cloud environments, hardened configurations likely include up-to-date security patches, security configuration, and security services, such as logging and monitoring. In traditional on- premises IT deployments, a stack might include an operating system, a database, an application server, and a runtime environment (e.g., a LAMP stack). Standards for secure use of reusable technologies, such as containers, microservices, or orchestration code, means that getting security right in one place positively impacts the security posture of all downstream efforts (see [SE2.5]).",
            "parent": "intelligence-sr"
          },
          {
            "bom-ref": "AA1.1",
            "identifier": "AA1.1",
            "title": "Perform security feature review.",
            "text": "Security-aware reviewers identify application security features, review these features against application security requirements and runtime parameters, and determine if each feature can adequately perform its intended function--usually referred to as threat modeling. The goal is to quickly identify missing security features and requirements, or bad deployment configuration (authentication, access control, use of cryptography, etc.), and address them. For example, threat modeling would identify both a system that was subject to escalation of privilege attacks because of broken access control as well as a mobile application that incorrectly puts PII in local storage. Use of the firm's secure-by-design components often streamlines this process (see [SFD2.1]). Many modern applications are no longer simply \"3-tier\" but instead involve components architected to interact across a variety of tiers--browser/endpoint, embedded, web, microservices, orchestration engines, deployment pipelines, third-party SaaS, and so on. Some of these environments might provide robust security feature sets, whereas others might have key capability gaps that require careful analysis, so organizations should consider the applicability and correct use of security features across all tiers that constitute the architecture and operational environment.",
            "parent": "ssdl-touchpoints-aa"
          },
          {
            "bom-ref": "AA1.2",
            "identifier": "AA1.2",
            "title": "Perform design review for high-risk applications.",
            "text": "Perform a design review to determine whether security features and deployment configuration are resistant to attack in an attempt to break the design. The goal is to extend the more formulaic approach of a security feature review (see [AA1.1]) to model application behavior in the context of real-world attackers and attacks. Reviewers must have some experience beyond simple threat modeling to include performing detailed design reviews and breaking the design under consideration. Rather than security feature guidance, a design review should produce a set of flaws and a plan to mitigate them. An organization can use consultants to do this work, but it should participate actively. A review focused only on whether a software project has performed the right process steps won't generate useful results about flaws. Note that a sufficiently robust design review process can't be executed at CI/CD speed, so organizations should focus on a few high-risk applications to start (see [AA1.4]).",
            "parent": "ssdl-touchpoints-aa"
          },
          {
            "bom-ref": "AA1.4",
            "identifier": "AA1.4",
            "title": "Use a risk methodology to rank applications.",
            "text": "Use a defined risk methodology to collect information about each application in order to assign a risk classification and associated prioritization. It is important to use this information in prioritizing what applications or projects are in scope for testing, including security feature and design reviews. Information collection can be implemented via questionnaire or similar method, whether manual or automated. Information needed for classification might include, \"Which programming languages is the application written in?\" or \"Who uses the application?\" or \"Is the application's deployment software-orchestrated?\" Typically, a qualified member of the application team provides the information, but the process should be short enough to take only a few minutes. The SSG can use the answers to categorize the application as, for example, high, medium, or low risk. Because a risk questionnaire can be easy to game, it's important to put into place some spot-checking for validity and accuracy--an overreliance on self-reporting can render this activity useless.",
            "parent": "ssdl-touchpoints-aa"
          },
          {
            "bom-ref": "AA2.1",
            "identifier": "AA2.1",
            "title": "Perform architecture analysis using a defined process.",
            "text": "Define and use a process for architecture analysis (AA) that extends the design review (see [AA1.2]) to also document business risk in addition to technical flaws. The goal is to identify application design flaws as well as the associated risk (e.g., impact of exploitation), such as through frequency or probability analysis, to properly inform stakeholder risk management efforts. The AA process includes a standardized approach for thinking about attacks, vulnerabilities, and various security properties. The process is defined well enough that people outside the SSG can carry it out. It's important to document both the architecture under review and any security flaws uncovered, as well as risk information that people can understand and use. Microsoft Threat Modeling, Versprite PASTA, and Synopsys ARA are examples of such a process, although these will likely need to be tailored to a given environment. In some cases, performing AA and documenting business risk is done by different teams working together in a single process. Uncalibrated or ad hoc AA approaches don't count as a defined process.",
            "parent": "ssdl-touchpoints-aa"
          },
          {
            "bom-ref": "AA2.2",
            "identifier": "AA2.2",
            "title": "Standardize architectural descriptions.",
            "text": "Threat modeling, design review, or AA processes use an agreed-upon format (e.g., diagramming language and icons, not a Word document template) to describe architecture, including a means for representing data flow. Standardizing architecture descriptions between those who generate the models and those who analyze and annotate them makes analysis more tractable and scalable. High-level network diagrams, data flow, and authorization flows are always useful, but the model should also go into detail about how the software itself is structured. A standard architecture description can be enhanced to provide an explicit picture of information assets that require protection, including useful metadata. Standardized icons that are consistently used in diagrams, templates, and dry-erase board squiggles are especially useful, too.",
            "parent": "ssdl-touchpoints-aa"
          },
          {
            "bom-ref": "AA2.4",
            "identifier": "AA2.4",
            "title": "Have SSG lead design review efforts.",
            "text": "The SSG takes a lead role in performing design review (see [AA1.2]) to uncover flaws. Breaking down an architecture is enough of an art that the SSG, or other reviewers outside the application team, must be proficient, and proficiency requires practice. This practice might then enable, for example, champions to take the day-to-day lead while the SSG maintains leadership around knowledge and process. The SSG can't be successful on its own, either--it will likely need help from architects or implementers to understand the design. With a clear design in hand, the SSG might be able to carry out a detailed review with a minimum of interaction with the project team. Approaches to design review evolve over time, so it's wise to not expect to set a process and use it forever. Outsourcing design review might be necessary, but it's also an opportunity to participate and learn.",
            "parent": "ssdl-touchpoints-aa"
          },
          {
            "bom-ref": "AA3.1",
            "identifier": "AA3.1",
            "title": "Have engineering teams lead AA process.",
            "text": "Engineering teams lead AA to uncover technical flaws and document business risk. This effort requires a well-understood and well-documented process (see [AA2.1]). Even with a good process, consistency is difficult to attain because breaking architecture requires experience, so be sure to provide architects with SSG or outside expertise in an advisory capacity. Engineering teams performing AA might normally have responsibilities such as development, DevOps, cloud security, operations security, security architecture, or a variety of similar roles. The process is more useful if the AA team is different from the design team.",
            "parent": "ssdl-touchpoints-aa"
          },
          {
            "bom-ref": "AA3.2",
            "identifier": "AA3.2",
            "title": "Drive analysis results into standard design patterns.",
            "text": "Failures identified during threat modeling, design review, or AA are fed back to security and engineering teams so that similar mistakes can be prevented in the future through improved design patterns, whether local to a team or formally approved for everyone (see [SFD3.1]). This typically requires a root-cause analysis process that determines the cause of security flaws, searches for the process that should have prevented the flaw, and makes the necessary improvements in documented security design patterns. Note that security design patterns can interact in surprising ways that break security, so apply analysis processes even when vetted design patterns are in standard use. For cloud services, providers have learned a lot about how their platforms and services fail to resist attack and have codified this experience into patterns for secure use. Organizations that heavily rely on these services might base their application-layer patterns on those building blocks provided by the cloud service provider (for example, AWS CloudFormation and Azure Blueprints) when making their own.",
            "parent": "ssdl-touchpoints-aa"
          },
          {
            "bom-ref": "AA3.3",
            "identifier": "AA3.3",
            "title": "Make the SSG available as an AA resource or mentor.",
            "text": "To build organizational AA capability, the SSG advertises experts as resources or mentors for teams using the AA process (see [AA2.1]). This effort might enable, for example, security champions, site reliability engineers, DevSecOps engineers, and others to take the lead while the SSG offers advice. As one example, mentors help tailor AA process inputs (such as design or attack patterns) to make them more actionable for specific technology stacks. This reusable guidance helps protect the team's time so they can focus on the problems that require creative solutions rather than enumerating known bad habits. While the SSG might answer AA questions during office hours (see [T3.5]), they will often assign a mentor to work with a team, perhaps comprising both security-aware engineers and risk analysts, for the duration of the analysis. In the case of high-risk software, the SSG should play a more active mentorship role in applying the AA process.",
            "parent": "ssdl-touchpoints-aa"
          },
          {
            "bom-ref": "CR1.2",
            "identifier": "CR1.2",
            "title": "Perform opportunistic code review.",
            "text": "Perform code review for high-risk applications in an opportunistic fashion. Organizations can follow up a design review with a code review looking for security issues in source code and dependencies, and perhaps also in deployment artifact configuration (e.g., containers) and automation metadata (e.g., infrastructure-as-code). This informal targeting often evolves into a systematic approach. Manual code review could be augmented with the use of specific tools and services, but it has to be part of a proactive process. When new technologies pop up, new approaches to code review might become necessary.",
            "parent": "ssdl-touchpoints-cr"
          },
          {
            "bom-ref": "CR1.4",
            "identifier": "CR1.4",
            "title": "Use automated review tools.",
            "text": "Incorporate static analysis into the code review process to make the review more efficient and consistent. Automation won't replace human judgement, but it does bring definition to the review process and security expertise to reviewers who typically aren't security experts. Note that a specific tool might not cover an entire portfolio, especially when new languages are involved, so additional local effort might be useful. Some organizations might progress to automating tool use by instrumenting static analysis into source code management workflows (e.g., pull requests) and delivery pipeline workflows (build, package, and deploy) to make the review more efficient, consistent, and in line with release cadence. Whether use of automated tools is to review a portion of the source code incrementally, such as a developer committing new code or small changes, or to conduct full analysis by scanning the entire codebase, this service should be explicitly connected to a larger SSDL defect management process applied during software development. This effort is not useful when done just to \"check the security box\" on the path to deployment.",
            "parent": "ssdl-touchpoints-cr"
          },
          {
            "bom-ref": "CR1.5",
            "identifier": "CR1.5",
            "title": "Make code review mandatory for all projects.",
            "text": "A security-focused code review is mandatory for all software projects, with a lack of code review or unacceptable results stopping a release, slowing it down, or causing it to be recalled. While all projects must undergo code review, the process might be different for different kinds of projects. The review for low-risk projects might rely more heavily on automation (see [CR1.4]), for example, whereas high-risk projects might have no upper bound on the amount of time spent by reviewers. Having a minimum acceptable standard forces projects that don't pass to be fixed and reevaluated. A code review tool with nearly all the rules turned off (so it can run at CI/CD automation speeds, for example) won't provide sufficient defect coverage. Similarly, peer code review or tools focused on quality and style won't provide useful security results.",
            "parent": "ssdl-touchpoints-cr"
          },
          {
            "bom-ref": "CR1.7",
            "identifier": "CR1.7",
            "title": "Assign code review tool mentors.",
            "text": "Mentors show developers how to get the most out of code review tools, including configuration, triage, and remediation. Security champions, DevOps and site reliability engineers, and SSG members often make good mentors. Mentors could use office hours or other outreach to help developers establish the right configuration and get started on interpreting and remediating results. Alternatively, mentors might work with a development team for the duration of the first review they perform. Centralized use of a tool can be distributed into the development organization or toolchains over time through the use of tool mentors, but providing installation instructions and URLs to centralized tool downloads isn't the same as mentoring. Increasingly, mentorship extends to code review tools associated with deployment artifacts (e.g., container security) and infrastructure (e.g., cloud configuration).",
            "parent": "ssdl-touchpoints-cr"
          },
          {
            "bom-ref": "CR2.6",
            "identifier": "CR2.6",
            "title": "Use custom rules with automated code review tools.",
            "text": "Create and use custom rules in code review tools to help uncover security defects specific to the organization's coding standards, or to the framework-based or cloud-provided middleware it uses. The same group that provides tool mentoring (see [CR1.7]) will likely spearhead this customization. Custom rules are often explicitly tied to proper usage of technology stacks in a positive sense and avoidance of errors commonly encountered in a firm's codebase in a negative sense. Custom rules are also an easy way to check for adherence to coding standards (see [CR3.5]). To reduce the workload for everyone, many organizations also create rules to remove repeated false positives and to turn off checks that aren't relevant.",
            "parent": "ssdl-touchpoints-cr"
          },
          {
            "bom-ref": "CR2.7",
            "identifier": "CR2.7",
            "title": "Use a top N bugs list (real data preferred).",
            "text": "Maintain a living list of the most important kinds of bugs the organization wants to eliminate from its code and use it to drive change. Many organizations start with a generic list pulled from public sources, but broad-based lists such as the OWASP Top 10 rarely reflect an organization's bug priorities. The list's value comes from being specific to the organization, being built from real data gathered from code review (see [CR2.8]), testing (see [PT1.2]), software composition analysis (see [SE3.8]), and actual incidents (see [CMVM1.1]), then being prioritized for prevention efforts. Simply sorting the day's bug data by number of occurrences won't produce a satisfactory list because the data changes so often. To increase interest, the SSG can periodically publish a \"most wanted\" report after updating the list. One potential pitfall with a top N list is that it tends to include only known problems. Of course, just building the list won't accomplish anything--everyone has to use it to find and fix bugs.",
            "parent": "ssdl-touchpoints-cr"
          },
          {
            "bom-ref": "CR2.8",
            "identifier": "CR2.8",
            "title": "Use centralized defect reporting to close the knowledge",
            "text": "loop. The bugs found during code review are tracked in a centralized repository that makes it possible to do both summary and trend reporting for the organization. The code review information is usually incorporated into a CISO-level dashboard that can include feeds from other security testing efforts (e.g., penetration testing, composition analysis, threat modeling). Given the historical code review data, the SSG can also use the reports to demonstrate progress (see [SM3.3]), then, for example, drive the training curriculum. Individual bugs make excellent training examples (see [T2.8]). Some organizations have moved toward analyzing this data and using the results to drive automation (see [ST3.6]).",
            "parent": "ssdl-touchpoints-cr"
          },
          {
            "bom-ref": "CR3.2",
            "identifier": "CR3.2",
            "title": "Build a capability to combine AST results.",
            "text": "Combine application security testing results so that multiple testing techniques feed into one reporting and remediation process. In addition to code review, testing techniques often include dynamic analysis, software composition analysis, container scanning, cloud services configuration review, and so on. The SSG might write scripts or acquire software to gather data automatically and combine the results into a format that can be consumed by a single downstream review and reporting solution. The tricky part of this activity is normalizing vulnerability information from disparate sources that might use conflicting terminology or scoring. In some cases, using a standardized taxonomy (e.g., a CWE-like approach) can help with normalization. Combining multiple sources helps drive better- informed risk mitigation decisions.",
            "parent": "ssdl-touchpoints-cr"
          },
          {
            "bom-ref": "CR3.3",
            "identifier": "CR3.3",
            "title": "Create capability to eradicate bugs.",
            "text": "When a security bug is found during code review (see [CR1.2], [CR1.4]), the organization searches for then fixes all occurrences of the bug, not just the instance originally discovered. Searching with custom rules (see [CR2.6]) makes it possible to eradicate the specific bug entirely without waiting for every project to reach the code review portion of its lifecycle. This doesn't mean finding every instance of every kind of cross-site scripting bug when a specific example is found--it means going after that specific example everywhere. A firm with only a handful of software applications built on a single technology stack will have an easier time with this activity than firms with many large applications built on a diverse set of technology stacks. A new development framework or library, rules in RASP or a next-generation firewall, or cloud configuration tools that provide guardrails can often help in (but not replace) eradication efforts.",
            "parent": "ssdl-touchpoints-cr"
          },
          {
            "bom-ref": "CR3.4",
            "identifier": "CR3.4",
            "title": "Automate malicious code detection.",
            "text": "Use automated code review to identify malicious code written by in-house developers or outsource providers. Examples of malicious code include backdoors, logic bombs, time bombs, nefarious communication channels, obfuscated program logic, and dynamic code injection. Although out-of-the-box automation might identify some generic malicious-looking constructs, custom rules for the static analysis tools used to codify acceptable and unacceptable patterns in the organization's codebase will likely become a necessity. Manual review for malicious code is a good start but insufficient to complete this activity at scale. While not all backdoors or similar code were meant to be malicious when they were written (e.g., a developer's feature to bypass authentication during testing), such things tend to stay in deployed code and should be treated as malicious until proven otherwise. Discovering some types of malicious code will require dynamic testing techniques.",
            "parent": "ssdl-touchpoints-cr"
          },
          {
            "bom-ref": "CR3.5",
            "identifier": "CR3.5",
            "title": "Enforce secure coding standards.",
            "text": "A violation of secure coding standards is sufficient grounds for rejecting a piece of code. This rejection can take one or more forms, such as denying a pull request, breaking a build, failing quality assurance, removal from production, or moving the code into a different development workstream where repairs or exceptions can be worked out. The enforced portions of an organization's secure coding standards (see [SR3.3]) often start out as a simple list of banned functions or required frameworks. Code review against standards must be objective--it shouldn't become a debate about whether the noncompliant code is exploitable. In some cases, coding standards are specific to language constructs and enforced with tools (e.g., codified into SAST rules). In other cases, published coding standards are specific to technology stacks and enforced during the code review process or by using automation. Standards can be positive (\"do it this way\") or negative (\"do not use this API\"), but they must be enforced.",
            "parent": "ssdl-touchpoints-cr"
          },
          {
            "bom-ref": "ST1.1",
            "identifier": "ST1.1",
            "title": "Perform edge/boundary value condition testing during QA.",
            "text": "QA efforts go beyond functional testing to perform basic adversarial tests and probe simple edge cases and boundary conditions, with no particular attacker skills required. When QA pushes past standard functional testing that uses expected input, it begins to move toward thinking like an adversary. Boundary value testing, whether automated or manual, can lead naturally to the notion of an attacker probing the edges on purpose (for example, determining what happens when someone enters the wrong password over and over).",
            "parent": "ssdl-touchpoints-st"
          },
          {
            "bom-ref": "ST1.3",
            "identifier": "ST1.3",
            "title": "Drive tests with security requirements and security",
            "text": "features. QA targets declarative security mechanisms with tests derived from security requirements and security features. A test could try to access administrative functionality as an unprivileged user, for example, or verify that a user account becomes locked after some number of failed authentication attempts. For the most part, security features can be tested in a fashion similar to other software features--security mechanisms such as account lockout, transaction limitations, entitlements, and so on are tested with both expected and unexpected input as derived from security requirements. Software security isn't security software, but testing security features is an easy way to get started. New software architectures and deployment automation, such as with container and cloud infrastructure orchestration, might require novel test approaches.",
            "parent": "ssdl-touchpoints-st"
          },
          {
            "bom-ref": "ST1.4",
            "identifier": "ST1.4",
            "title": "Integrate opaque-box security tools into the QA process.",
            "text": "The organization uses one or more opaque-box security testing tools as part of the QA process. Such tools are valuable because they encapsulate an attacker's perspective, albeit generically. Traditional dynamic analysis scanners are relevant for web applications, while similar tools exist for cloud environments, containers, mobile applications, embedded systems, and so on. In some situations, other groups might collaborate with the SSG to apply the tools. For example, a testing team could run the tool but come to the SSG for help with interpreting the results. When testing is integrated into Agile development approaches, opaque-box tools might be hooked into internal toolchains, provided by cloud-based toolchains, or used directly by engineering. Regardless of who runs the opaque-box tool, the testing should be properly integrated into a QA cycle of the SSDL and will often include both authenticated and unauthenticated reviews.",
            "parent": "ssdl-touchpoints-st"
          },
          {
            "bom-ref": "ST2.4",
            "identifier": "ST2.4",
            "title": "Drive QA tests with AST results.",
            "text": "Share results from application security testing, such as penetration testing, threat modeling, composition analysis, code reviews, etc., with QA teams to evangelize the security mindset. Using security defects as the basis for a conversation about common attack patterns or the underlying causes allows QA teams to generalize this information into new test approaches. Organizations that leverage software pipeline platforms such as GitHub, or CI/CD platforms such as the Atlassian stack, can benefit from teams receiving various testing results automatically, which should then facilitate timely stakeholder conversations--emailing security reports to QA teams will not generate the desired results. Over time, QA teams learn the security mindset, and the organization benefits from an improved ability to create security tests tailored to the organization's code.",
            "parent": "ssdl-touchpoints-st"
          },
          {
            "bom-ref": "ST2.5",
            "identifier": "ST2.5",
            "title": "Include security tests in QA automation.",
            "text": "Security tests are included in an automation framework and run alongside functional, performance, and other QA test suites. Executing this automation framework can be triggered manually or through additional automation (e.g., as part of pipeline tooling). When test creators who understand the software create security tests, they can uncover more specialized or more relevant defects than commercial tools might (see [ST1.4]). Security tests might be derived from typical failures of security features (see [SFD1.1]), from creative tweaks of functional and developer tests, or even from guidance provided by penetration testers on how to reproduce an issue. Tests that are performed manually or out-of-band likely will not provide timely feedback.",
            "parent": "ssdl-touchpoints-st"
          },
          {
            "bom-ref": "ST2.6",
            "identifier": "ST2.6",
            "title": "Perform fuzz testing customized to application APIs.",
            "text": "QA efforts include running a customized fuzzing framework against APIs critical to the organization. An API might be software that allows two applications to communicate or even software that allows a human to interact with an application (e.g., a webform). Testers could begin from scratch or use an existing fuzzing toolkit, but the necessary customization often goes beyond creating custom protocol descriptions or file format templates to giving the fuzzing framework a built-in understanding of the application interfaces and business logic. Test harnesses developed explicitly for specific applications make good places to integrate fuzz testing.",
            "parent": "ssdl-touchpoints-st"
          },
          {
            "bom-ref": "ST3.3",
            "identifier": "ST3.3",
            "title": "Drive tests with design review results.",
            "text": "Use design review or architecture analysis results to direct QA test creation. For example, if the results of attempting to break a design determine that \"the security of the system hinges on the transactions being atomic and not being interrupted partway through\" then torn transactions will become a primary target in adversarial testing. Adversarial tests like these can be developed according to a risk profile, with high-risk flaws at the top of the list. Security defect data shared with QA (see [ST2.4]) can help focus test creation on areas of potential vulnerability that can, in turn, help prove the existence of identified high-risk flaws.",
            "parent": "ssdl-touchpoints-st"
          },
          {
            "bom-ref": "ST3.4",
            "identifier": "ST3.4",
            "title": "Leverage code coverage analysis.",
            "text": "Testers measure the code coverage of their application security testing to identify code that isn't being exercised and then adjust test cases to incrementally improve coverage. AST can include automated testing (see [ST2.5], [ST2.6]) and manual testing (see [ST1.1], [ST1.3]). In turn, code coverage analysis drives increased security testing depth. Coverage analysis is easier when using standard measurements such as function coverage, line coverage, or multiple condition coverage. Measuring how broadly the test cases cover security requirements is not the same as measuring how broadly the test cases exercise the code. Note that standard-issue opaque-box testing tools (e.g., web application scanners, see [ST1.4]) provide exceptionally low coverage, leaving much of the software under test unexplored.",
            "parent": "ssdl-touchpoints-st"
          },
          {
            "bom-ref": "ST3.5",
            "identifier": "ST3.5",
            "title": "Begin to build and apply adversarial security tests (abuse",
            "text": "cases). QA teams incorporate test cases based on abuse cases (see [AM2.1]) as testers move beyond verifying functionality and take on the attacker's perspective. One way to do this is to systematically attempt to replicate incidents from the organization's history. Abuse and misuse cases based on the attacker's perspective can also be derived from security policies, attack intelligence, standards, and the organization's top N attacks list (see [AM2.5]). This effort turns the corner in QA from testing features to attempting to break the software under test.",
            "parent": "ssdl-touchpoints-st"
          },
          {
            "bom-ref": "ST3.6",
            "identifier": "ST3.6",
            "title": "Implement event-driven security testing in automation.",
            "text": "The SSG guides implementation of automation for continuous, event-driven application security testing. An event here is simply a noteworthy occurrence, such as dropping new code in a repository, a pull request, a build request, a push to deployment, or a Tuesday at noon. Event-driven testing implemented in pipeline automation typically moves the testing closer to the conditions driving the testing requirement (whether shift left toward design or shift right toward operations), repeats the testing as often as the event is triggered, and helps ensure that the right testing is executed for a given set of conditions. Success with this approach depends on the broad use of sensors (e.g., agents, bots) that monitor engineering processes, execute contextual rules, and provide telemetry to automation that initiates the specified testing whenever event conditions are met. More mature configurations proceed to including risk-driven conditions (e.g., size of change, provenance, function, team).",
            "parent": "ssdl-touchpoints-st"
          },
          {
            "bom-ref": "PT1.1",
            "identifier": "PT1.1",
            "title": "Use external penetration testers to find problems.",
            "text": "External penetration testers are used to demonstrate that the organization's software needs help. Finding critical vulnerabilities in high-profile applications provides the evidence that executives often require. Over time, the focus of penetration testing moves from trying to determine if the code is broken in some areas to a sanity check done before shipping or on a periodic basis. External penetration testers who bring a new set of experiences and skills to the problem are the most useful.",
            "parent": "deployment-pt"
          },
          {
            "bom-ref": "PT1.2",
            "identifier": "PT1.2",
            "title": "Feed results to the defect management and mitigation",
            "text": "system. All penetration testing results are fed back to engineering through established defect management or mitigation channels, with development and operations responding via a defect management and release process. In addition to application vulnerabilities, also track results from testing other software such as containers and infrastructure configuration. Properly done, this exercise demonstrates the organization's ability to improve the state of security and emphasizes the importance of not just identifying but actually fixing security problems. One way to ensure attention is to add a security flag to the bug-tracking and defect management system. The organization might leverage developer workflow or social tooling (e.g., JIRA, Slack) to communicate change requests, but these requests are still tracked explicitly as part of a vulnerability management process.",
            "parent": "deployment-pt"
          },
          {
            "bom-ref": "PT1.3",
            "identifier": "PT1.3",
            "title": "Use penetration testing tools internally.",
            "text": "The organization creates an internal penetration testing capability that uses tools as part of an established process. Execution can be part of the SSG or part of a specialized team elsewhere in the organization, with the tools complementing manual efforts to improve the efficiency and repeatability of the testing process. The tools used will usually include off-the-shelf products built specifically for application penetration testing, network penetration tools that specifically understand the application layer, container and cloud configuration testing tools, and custom scripts. Free-time or crisis- driven efforts aren't the same as an internal capability.",
            "parent": "deployment-pt"
          },
          {
            "bom-ref": "PT2.2",
            "identifier": "PT2.2",
            "title": "Penetration testers use all available information.",
            "text": "Penetration testers, whether internal or external, routinely make use of all artifacts created throughout the SSDL to do more comprehensive analysis and find more problems. Example artifacts include source code, design documents, architecture analysis results, misuse and abuse cases, code review results, and cloud environment and other deployment configurations. Focusing on high-risk applications is a good way to start. An SSDL that creates no useful artifacts about the code will make this effort harder. Having access to the artifacts is not the same as using them.",
            "parent": "deployment-pt"
          },
          {
            "bom-ref": "PT2.3",
            "identifier": "PT2.3",
            "title": "Schedule periodic penetration tests for application",
            "text": "coverage. All applications are tested periodically, which could be tied to a calendar or a release cycle. High-risk applications could get a penetration test at least once per year, for example, even if there have not been substantive code changes--other applications might receive different kinds of security testing on a similar schedule. Any security testing performed must focus on discovering vulnerabilities, not just checking a process or compliance box. This testing serves as a sanity check and helps ensure that yesterday's software isn't vulnerable to today's attacks. The testing can also help maintain the security of software configurations and environments, especially for containers and components in the cloud. One important aspect of periodic security testing across the portfolio is to make sure that the problems identified are actually fixed. Software that isn't an application, such as automation created for CI/CD, infrastructure-as- code, and so on, deserves some security testing as well.",
            "parent": "deployment-pt"
          },
          {
            "bom-ref": "PT3.1",
            "identifier": "PT3.1",
            "title": "Use external penetration testers to perform deep-dive",
            "text": "analysis. The SSG uses external penetration testers to do a deep-dive analysis on critical software systems or technologies and to introduce fresh thinking. One way to do this is to simulate persistent attackers using goal-oriented red team exercises. These testers are domain experts and specialists who keep the organization up to speed with the latest version of the attacker's perspective and have a track record for breaking the type of software being tested. When attacking the organization's software, these testers demonstrate a creative approach that provides useful knowledge to the people designing, implementing, and hardening new systems. Creating new types of attacks from threat intelligence and abuse cases typically requires extended timelines, which is essential when it comes to new technologies, and prevents checklist-driven approaches that look only for known types of problems.",
            "parent": "deployment-pt"
          },
          {
            "bom-ref": "PT3.2",
            "identifier": "PT3.2",
            "title": "Customize penetration testing tools.",
            "text": "Build a capability to create penetration testing tools or adapt publicly available ones to attack the organization's software more efficiently and comprehensively. Creating penetration testing tools requires a deep understanding of attacks (see [AM2.1], [AM3.1]) and technology stacks (see [AM2.2]). Customizing existing tools goes beyond configuration changes and extends tool functionality to find new issues. Tools will improve the efficiency of the penetration testing process without sacrificing the depth of problems that the SSG can identify. Automation can be particularly valuable in organizations using Agile methodologies because it helps teams go faster. Tools that can be tailored are always preferable to generic tools. Success here is often dependent upon both the depth and scope of tests enabled through customized tools.",
            "parent": "deployment-pt"
          },
          {
            "bom-ref": "SE1.1",
            "identifier": "SE1.1",
            "title": "Use application input monitoring.",
            "text": "The organization monitors input to the software that it runs in order to spot attacks. Monitoring systems that write log files are useful only if humans or bots periodically review the logs and take action. For web applications, a WAF can do this monitoring, while other kinds of software likely require other approaches, such as runtime instrumentation. Software and technology stacks such as mobile and IoT likely require their own input monitoring solutions. Serverless and containerized software can require interaction with vendor software to get the appropriate logs and monitoring data. Cloud deployments and platform-as-a-service usage can add another level of difficulty to the monitoring, collection, and aggregation approach.",
            "parent": "deployment-se"
          },
          {
            "bom-ref": "SE1.2",
            "identifier": "SE1.2",
            "title": "Ensure host and network security basics are in place.",
            "text": "The organization provides a solid foundation for its software by ensuring that host (whether bare metal or virtual machine) and network security basics are in place across its data centers and networks, and that these basics remain in place during new releases. Host and network security basics must account for evolving network perimeters, increased connectivity and data sharing, software-defined networking, and increasing dependence on vendors (e.g., content delivery, load balancing, and content inspection services). Doing software security before getting host and network security in place is like putting on shoes before putting on socks.",
            "parent": "deployment-se"
          },
          {
            "bom-ref": "SE1.3",
            "identifier": "SE1.3",
            "title": "Implement cloud security controls.",
            "text": "Organizations ensure that cloud security controls are in place and working for both public and private clouds. Industry best practices are a good starting point for local policy and standards to drive controls and configurations. Of course, cloud-based assets often have public-facing services that create an attack surface (e.g., cloud-based storage) that is different from the one in a private data center, so these assets require customized security configuration and administration. In the increasingly software-defined world, the SSG has to help everyone explicitly configure cloud-specific security features and controls (e.g., through cloud provider administration consoles) comparable to those built with cables and physical hardware in private data centers. Detailed knowledge about cloud provider shared responsibility security models is always necessary to ensure that the right cloud security controls remain in place.",
            "parent": "deployment-se"
          },
          {
            "bom-ref": "SE2.2",
            "identifier": "SE2.2",
            "title": "Define secure deployment parameters and configurations.",
            "text": "Create deployment automation or installation guides (e.g., standard operating procedures) to help teams and customers install and configure software securely. Deployment automation usually includes a clearly described configuration for software artifacts and the infrastructure-as-code (e.g., Terraform, CloudFormation, ARM templates, Helm Charts) necessary to deploy them, including details on COTS, open source, vendor, and cloud services components. All deployment automation should be understandable by humans, not just by machines, especially when distributed to customers who buy the software.",
            "parent": "deployment-se"
          },
          {
            "bom-ref": "SE2.4",
            "identifier": "SE2.4",
            "title": "Protect code integrity.",
            "text": "Use code protection mechanisms (e.g., code signing) that allow the organization to attest to the provenance, integrity, and authorization of important code. While legacy and mobile platforms accomplished this with point-in-time code signing and permissions activity, protecting modern containerized software demands actions in various lifecycle phases. Organizations can use build systems to verify sources and manifests of dependencies, creating their own cryptographic attestation of both. Packaging and deployment systems can sign and verify binary packages, including code, configuration, metadata, code identity, and authorization to release material. In some cases, organizations allow only code from their own registries to execute in certain environments. With many DevOps practices greatly increasing the number of people who can touch the code, organizations should also use permissions and peer review to govern code commits within source code management to help protect integrity.",
            "parent": "deployment-se"
          },
          {
            "bom-ref": "SE2.5",
            "identifier": "SE2.5",
            "title": "Use application containers to support security goals.",
            "text": "The organization uses application containers to support its software security goals. Simply deploying containers isn't sufficient to gain security benefits, while their planned use could support a tighter coupling of applications with their dependencies, immutability, integrity (see [SE2.4]), and some isolation benefits without the overhead of deploying a full operating system on a virtual machine. Containers are a convenient place for security controls to be applied and updated consistently (see [SFD3.2]), and while they are useful in development and test environments, their use in production provides the needed security benefits.",
            "parent": "deployment-se"
          },
          {
            "bom-ref": "SE2.7",
            "identifier": "SE2.7",
            "title": "Use orchestration for containers and virtualized",
            "text": "environments. The organization uses automation to scale service, container, and virtualized environments in a disciplined way. Orchestration processes take advantage of built-in and add-on security features (see [SFD2.1]), such as hardening against drift, secrets management, RBAC, and rollbacks, to ensure that each deployed workload meets predetermined security requirements. Setting security behaviors in aggregate allows for rapid change when the need arises. Orchestration platforms are themselves software that becomes part of your production environment, which in turn requires hardening and security patching and configuration--in other words, if you use Kubernetes, make sure you patch Kubernetes.",
            "parent": "deployment-se"
          },
          {
            "bom-ref": "SE3.2",
            "identifier": "SE3.2",
            "title": "Use code protection.",
            "text": "To protect intellectual property and make exploit development harder, the organization erects barriers to reverse engineering its software (e.g., anti-tamper, debug protection, anti-piracy features, runtime integrity). For some software, obfuscation techniques could be applied as part of the production build and release process. In other cases, these protections could be applied at the software-defined network or software orchestration layer when applications are being dynamically regenerated post-deployment. Code protection is particularly important for widely distributed code, such as mobile applications and JavaScript distributed to browsers. On some platforms, employing Data Execution Prevention (DEP), Safe Structured Handling (SafeSEH), and Address Space Layout Randomization (ASLR) can be a good start at making exploit development more difficult, but be aware that yesterday's protection mechanisms might not hold up to today's attacks.",
            "parent": "deployment-se"
          },
          {
            "bom-ref": "SE3.3",
            "identifier": "SE3.3",
            "title": "Use application behavior monitoring and diagnostics.",
            "text": "The organization monitors production software to look for misbehavior or signs of attack. Go beyond host and network monitoring to look for software-specific problems, such as indications of malicious behavior, fraud, and related issues. Application-level intrusion detection and anomaly detection systems might focus on an application's interaction with the operating system (through system calls) or with the kinds of data that an application consumes, originates, and manipulates. Signs that an application isn't behaving as expected will be specific to the software business logic and its environment, so one-size-fits-all solutions probably won't generate satisfactory results. In some types of environments (e.g., PaaS), some of this data and the associated predictive analytics might come from a vendor.",
            "parent": "deployment-se"
          },
          {
            "bom-ref": "SE3.6",
            "identifier": "SE3.6",
            "title": "Create bills of materials for deployed software.",
            "text": "Create a BOM detailing the components, dependencies, and other metadata for important production software. Use this BOM to help the organization tighten its security posture, that is, to react with agility as attackers and attacks evolve, compliance requirements change, and the number of items to patch grows quite large. Knowing where all the components live in running software--and whether they're in private data centers, in clouds, or sold as box products (see [CMVM2.3])--allows for timely response when unfortunate events occur.",
            "parent": "deployment-se"
          },
          {
            "bom-ref": "SE3.8",
            "identifier": "SE3.8",
            "title": "Perform application composition analysis on code",
            "text": "repositories. Use composition analysis results to augment software asset inventory information with data on all components comprising important applications. Beyond open source (see [SR2.4]), inventory information (see [SM3.1]) includes component and dependency information for internally developed (first-party), commissioned code (second-party), and external (third-party) software, whether that software exists as source code or binary. One common way of documenting this information is to build BOMs. Doing this manually is probably not an option--keeping up with software changes likely requires toolchain integration rather than carrying this out as a point- in-time activity. This information is extremely useful in supply chain security efforts (see [SM3.5]).",
            "parent": "deployment-se"
          },
          {
            "bom-ref": "CMVM1.1",
            "identifier": "CMVM1.1",
            "title": "Create or interface with incident response.",
            "text": "The SSG is prepared to respond to an event or alert and is regularly included in the incident response process, either by creating its own incident response capability or by regularly interfacing with the organization's existing team. A standing meeting between the SSG and the incident response team keeps information flowing in both directions. Having prebuilt communication channels with critical vendors (e.g., IaaS, SaaS, PaaS) is also very important.",
            "parent": "deployment-cmvm"
          },
          {
            "bom-ref": "CMVM1.2",
            "identifier": "CMVM1.2",
            "title": "Identify software defects found in operations monitoring",
            "text": "and feed them back to engineering. Defects identified in production through operations monitoring are fed back to development and used to change engineering behavior. Useful sources of production defects include incidents, bug bounty (see [CMVM3.4]), responsible disclosure (see [CMVM3.7]), SIEMs, production logs, and telemetry from cloud security posture monitoring, container configuration monitoring, RASP, and similar products. Entering production defect data into an existing bug- tracking system (perhaps by making use of a special security flag) can close the information loop and make sure that security issues get fixed. In addition, it's important to capture lessons learned from production defects and use these lessons to change the organization's behavior. In the best of cases, processes in the SSDL can be improved based on operations data (see [CMVM3.2]).",
            "parent": "deployment-cmvm"
          },
          {
            "bom-ref": "CMVM2.1",
            "identifier": "CMVM2.1",
            "title": "Have emergency response.",
            "text": "The organization can make quick code and configuration changes when software (e.g., application, API, microservice, infrastructure) is under attack. An emergency response team works in conjunction with application owners, engineering, operations, and the SSG to study the code and the attack, find a resolution, and fix the production code (e.g., push a patch into production, rollback to a known-good state, deploy a new container). Often, the emergency response team is the engineering team itself. A well-defined process is a must here, but a process that has never been used might not actually work.",
            "parent": "deployment-cmvm"
          },
          {
            "bom-ref": "CMVM2.2",
            "identifier": "CMVM2.2",
            "title": "Track software defects found in operations through the",
            "text": "fix process. Defects found in operations (see [CMVM1.2]) are entered into established defect management systems and tracked through the fix process. This capability could come in the form of a two-way bridge between defect finders and defect fixers or possibly through intermediaries, but make sure the loop is closed completely. Defects can appear in all types of deployable artifacts, deployment automation, and infrastructure configuration. Setting a security flag in the defect-tracking system can help facilitate tracking.",
            "parent": "deployment-cmvm"
          },
          {
            "bom-ref": "CMVM2.3",
            "identifier": "CMVM2.3",
            "title": "Develop an operations software inventory.",
            "text": "The organization has a map of its software deployments and related containerization, orchestration, and deployment automation code, along with the respective owners. If a software asset needs to be changed or decommissioned, operations or DevOps teams can reliably identify both the stakeholders and all the places where the change needs to occur. Common components can be noted so that when an error occurs in one application, other applications sharing the same components can be fixed as well. Building an accurate representation of an inventory will likely involve enumerating at least the source code, the open source incorporated both during the build and during dynamic production updates, the orchestration software incorporated into production images, and any service discovery or invocation that occurs in production.",
            "parent": "deployment-cmvm"
          },
          {
            "bom-ref": "CMVM3.1",
            "identifier": "CMVM3.1",
            "title": "Fix all occurrences of software defects found in",
            "text": "operations. When a security defect is found in operations (see [CMVM1.2]), the organization searches for and fixes all occurrences of the defect, not just the one originally reported. Doing this proactively requires the ability to reexamine the entire operations software inventory (see [CMVM2.3]) when new kinds of defects come to light. One way to approach reexamination is to create a ruleset that generalizes deployed defects into something that can be scanned for via automated code review. In some environments, fixing a defect might involve removing it from production immediately and making the actual fix in some priority order before redeployment. Use of orchestration can greatly simplify deploying the fix for all occurrences of a software defect (see [SE2.7]).",
            "parent": "deployment-cmvm"
          },
          {
            "bom-ref": "CMVM3.2",
            "identifier": "CMVM3.2",
            "title": "Enhance the SSDL to prevent software defects found in",
            "text": "operations. Experience from operations leads to changes in the SSDL (see [SM1.1]), which can in turn be strengthened to prevent the reintroduction of defects. To make this process systematic, incident response postmortem includes a feedback-to-SSDL step. The outcomes of the postmortem might result in changes such as to tool-based policy rulesets in a CI/CD pipeline and adjustments to automated deployment configuration (see [SE2.2]). This works best when root-cause analysis pinpoints where in the software lifecycle an error could have been introduced or slipped by uncaught (e.g., a defect escape). DevOps engineers might have an easier time with this because all the players are likely involved in the discussion and the solution. An ad hoc approach to SSDL improvement isn't sufficient for prevention.",
            "parent": "deployment-cmvm"
          },
          {
            "bom-ref": "CMVM3.3",
            "identifier": "CMVM3.3",
            "title": "Simulate software crises.",
            "text": "The SSG simulates high-impact software security crises to ensure that software incident detection and response capabilities minimize damage. Simulations could test for the ability to identify and mitigate specific threats or, in other cases, begin with the assumption that a critical system or service is already compromised and evaluate the organization's ability to respond. Planned chaos engineering can be effective at triggering unexpected conditions during simulations. The exercises must include attacks or other software security crises at the appropriate software layer to generate useful results (e.g., at the application layer for web applications and at lower layers for IoT devices). When simulations model successful attacks, an important question to consider is the time required to clean up. Regardless, simulations must focus on security-relevant software failure, not on natural disasters or other types of emergency response drills. Organizations that are highly dependent on vendor infrastructure (e.g., cloud service providers, SaaS, PaaS) and security features will naturally include those things in crisis simulations.",
            "parent": "deployment-cmvm"
          },
          {
            "bom-ref": "CMVM3.4",
            "identifier": "CMVM3.4",
            "title": "Operate a bug bounty program.",
            "text": "The organization solicits vulnerability reports from external researchers and pays a bounty for each verified and accepted vulnerability received. Payouts typically follow a sliding scale linked to multiple factors, such as vulnerability type (e.g., remote code execution is worth $10,000 vs. CSRF is worth $750), exploitability (demonstrable exploits command much higher payouts), or specific service and software versions (widely deployed or critical services warrant higher payouts). Ad hoc or short-duration activities, such as capture-the-flag contests or informal crowdsourced efforts, don't constitute a bug bounty program.",
            "parent": "deployment-cmvm"
          },
          {
            "bom-ref": "CMVM3.5",
            "identifier": "CMVM3.5",
            "title": "Automate verification of operational infrastructure",
            "text": "security. The SSG works with engineering teams to verify with automation the security properties (e.g., adherence to agreed-upon security hardening) of infrastructure generated from controlled self-service processes. Engineers use self-service processes to create networks, storage, containers, and machine instances, to orchestrate deployments and to perform other tasks that were once IT's sole responsibility. In facilitating verification, the organization uses machine-readable policies and configuration standards (see [SE2.2]) to automatically detect issues and report on infrastructure that does not meet expectations. In some cases, the automation makes changes to running environments to bring them into compliance, but in many cases, organizations use a single policy to manage automation in different environments, such as in multi- and hybrid- cloud environments.",
            "parent": "deployment-cmvm"
          },
          {
            "bom-ref": "CMVM3.6",
            "identifier": "CMVM3.6",
            "title": "Publish risk data for deployable artifacts.",
            "text": "The organization collects and publishes risk information about the applications, services, APIs, containers, and other software it deploys. Whether captured through manual processes or telemetry automation, published information extends beyond basic software security (see [SM2.1]) and inventory data (see [CMVM2.3]) to include risk information. This information usually includes constituency of the software (e.g., BOMs, [SE3.6]), what group created it and how, and the risks associated with known vulnerabilities, deployment models, security controls, or other security characteristics intrinsic to each artifact. This approach stimulates cross-functional coordination and helps stakeholders take informed risk management action. Making a list of risks that aren't used for decision support won't achieve useful results.",
            "parent": "deployment-cmvm"
          },
          {
            "bom-ref": "CMVM3.7",
            "identifier": "CMVM3.7",
            "title": "Streamline incoming responsible vulnerability disclosure.",
            "text": "Provide external bug reporters with a line of communication to internal security experts through a low-friction, public entry point. These experts work with bug reporters to invoke any necessary organizational responses and to coordinate with the external entities throughout the defect management lifecycle. Successful disclosure processes require insight from internal stakeholders such as legal, marketing, and public relations roles to simplify and expedite decision-making during software security crises. Although bug bounties might be important to motivate some researchers (see [CMVM3.4]), proper public attribution and a low-friction reporting process is often sufficient motivation for researchers to participate in a coordinated disclosure. Most organizations will use a combination of easy-to-find landing pages, common email addresses (security@), and embedded product documentation when appropriate (security. txt) as an entry point for external reporters to invoke this process.",
            "parent": "deployment-cmvm"
          },
          {
            "bom-ref": "CMVM3.8",
            "identifier": "CMVM3.8",
            "title": "Do attack surface management for deployed applications.",
            "text": "Operations standards and procedures proactively minimize application attack surfaces by using attack intelligence and application weakness data to limit vulnerable conditions. Finding and fixing software bugs in operations is important (see [CMVM1.2]) but so is finding and fixing errors in cloud security models, VPNs, segmentation, security configurations for networks, hosts, and applications, and so on to limit the ability to successfully attack deployed applications. Combining attack intelligence (see [AM1.5]) with information about software assets (see [AM3.3]) and a continuous view of application weaknesses helps ensure that attack surface management keeps pace with attacker methods. SBOMs (see [SE3.6]) are also an important information source when doing attack surface management in a crisis.",
            "parent": "deployment-cmvm"
          }
        ],
        "externalReferences": [
          {
            "type": "documentation",
            "url": "https://www.synopsys.com/software-integrity/engage/bsimm-web/bsimm13-foundations",
            "comment": "BSIMM 13 Foundations Report 2022"
          },
          {
            "type": "website",
            "url": "https://bsimm.com"
          }
        ]
      }
    ]
  }
}