RFP 19GT5025R0004 - Guatemala US Embassy Main Internet Circuit Services.pdf

Guatemala, November 26, 2024

Dear Potential Offeror:

Subject: Request for Proposal number 19GT5025R0004

Enclosed is a Request for Proposals (RFP) for Guatemala US Embassy Main Internet Circuit Services. If you would like to submit a proposal, follow the instructions in Section 3 of the solicitation, complete the required portions of the attached document, and submit it to the address shown on the Standard Form 1449 that follows this letter.

The U.S. Government intends to award a contract to the responsible company submitting an acceptable proposal at the lowest price. We intend to award a contract based on initial proposals, without holding discussions, although we may hold discussions with companies in the competitive range if there is a need to do so.

The Embassy intends to conduct a pre-proposal conference via Microsoft Teams, the pre-proposal conference will be held on Wednesday, December 11, 2024, at 9:00 am (local time). Offerors should contact Ingrid Cifuentes by Monday, December 9, 2024, by 8:00am (local time) at CifuentesIG@state.gov for additional information or to request the invitation to participate in the conference.

Proposals are due by Monday, December 30, 2024, by 5:00 pm (local time). No proposals will be accepted after this time. Proposals must be in English and incomplete proposals will not be accepted.

Your proposal must be submitted electronically to GuatemalaBids@state.gov It is important to make sure the submission is made in specific size and format; in MS-Word 2007/2010 or MS-Excel 2007/2010 or Adobe Acrobat (pdf) file format. The file size must not exceed 30MB. If the file size should exceed the 30MB, the submission must be made in separate files and attached to separate emails with less than 30MB each.

For a proposal to be considered, you must also complete and submit the following:

1. SF-1449

2. Section I, Pricing

3. Section 5 Representations and Certifications

4. Additional information as required in Section 3

5. “The Offeror should submit a completed IRS Form W-14, found at www.irs.gov/w14, to ensure compliance with FAR 52.229-11;”

6. Proof of SAM Registration

7. CYBERSECURITY SUPPLY CHAIN RISK MANAGEMENT (C-SCRM) C-SCRM Questionnaire and C-SCRM Software Producer Attestation Form mailto:CifuentesIG@state.gov mailto:GuatemalaBids@state.gov http://www.irs.gov/w14

Offerors shall be registered in the SAM (System for Award Management) database at https://www.sam.gov prior to submittal of their offer/proposal as prescribed under FAR 4.1102. Failure to be registered at time of proposal submission shall deem the Offeror’s proposal to be considered non-responsive to the solicitation requirements and no further consideration will be given. Therefore, Offerors are highly encouraged to register immediately if they are interested in submitting a response to this requirement.

Sincerely, Beau P. Garrett Contracting Officer https://www.sam.gov/ x x x x x x x x x x x x x x x x x x x x x x x x

AUTORIZED FOR LOCAL REPRODUCTION STANDARD FORM 1449 (REV. 02/2012)

PREVIOUS EDITION IS NOT USABLE Computer Generated Prescribed by GSA - FAR (48 CFR) 53.212

SOLICITATION/CONTRACT/ORDER FOR COMMERCIAL ITEMS

OFFEROR TO COMPLETE BLOCKS 12, 17, 23, 24, & 30

1. REQUISITION NUMBER

PR15006909

PAGES

2. CONTRACT NO. 3. AWARD/ EFFECTIVE

DATE

4. ORDER NUMBER 5. SOLICITATION NUMBER

19GT5025R0004

6. SOLICITATION ISSUE

DATE

11/26/2024

7. FOR SOLICITATION

INFORMATION CALL:

a. NAME Ingrid G Cifuentes

b. TELEPHONE NUMBER(No collect calls) +502 3071-9635

8. OFFER DUE DATE/

LOCAL TIME

12/30/2024 / 17:00

9. ISSUED BY CODE GT500 10. THIS ACQUISITION IS UNRESTRICTED OR SET ASIDE: % FOR:

SMALL BUSINESS WOMEN-OWNED SMALL BUSINESS

HUBZONE SMALL

BUSINESS

(WOSB) ELLIGIBLE UNDER THE WOMEN-OWNED

SMALL BUSINESS PROGRAM NAICS:

EDWOSB EMERGING SMALL BUSINESS

AMERICAN EMBASSY GUATEMALA CITY

Boulevard Austriaco 11-51, Zona 16, ATTN: GSO -

PROCUREMENT SECTION

Guatemala

GUATEMALA

SERVICE-DISABLED

VETERAN-OWNED

SMALL BUSINESS 8 (A) SIZE STANDARD:

13b. RATING11. DELIVERY FOR FOB DESTINAT-

TION UNLESS BLOCK IS

MARKED

x SEE SCHEDULE

12. DISCOUNT TERMS 13a. THIS CONTRACT IS A

RATED ORDER UNDER

DPAS (15 CFR 700)

14. METHOD OF SOLICITATION

RFQ IFB x RFP

15. DELIVER TO CODE 16. ADMINISTERED BY CODE

AMERICAN EMBASSY GUATEMALA CITY

Boulevard Austriaco 11-51 Zona 16, ATTN:

IPO/IMO

GUATEMALA CITY

GUATEMALA

AMERICAN EMBASSY GUATEMALA CITY

Boulevard Austriaco 11-51, Zona 16, ATTN: GSO - PROCUREMENT SECTION Guatemala

GUATEMALA

CODE FACILITY

CODE

17a. CONTRACTOR/

OFFERER

TELEPHONE NO.

18a. PAYMENT WILL BE MADE BY

AMERICAN EMBASSY GUATEMALA CITY

Boulevard Austriaco 11-51 Zona 16, ATTN: GSO

GUATEMALA CITY

GUATEMALA

CODE

17b. CHECK IF REMITTANCE IS DIFFERENT AND PUT SUCH ADDRESS IN

OFFER

18b. SUBMIT INVOICES TO ADDRESS SHOWN IN BLOCK 18a UNLESS BLOCK

BELOW IS CHECKED SEE ADDENDUM

19.

ITEM NO.

20.

SCHEDULE OF SUPPLIES/SERVICES

21.

QUANTITY

22.

UNIT

23.

UNIT PRICE

24.

AMOUNT

(Use Reverse and/or Attach Additional Sheets as Necessary)

25. ACCOUNTING AND APPROPRIATION DATA 26. TOTAL AWARD AMOUNT (For Govt. Use Only) x 27a.SOLICITATION INCORPORATES BY REFERENCE FAR 52.212-1, 52.212-4. FAR 52.212-3 AND 52.212-5 ARE ATTACHED. ADDENDA x ARE ARE NOT ATTACHED

27b.CONTRACT/PURCHASE ORDER INCORPORATES BY REFERENCE FAR 52.212-4. FAR 52.212-5 IS ATTACHED. ADDENDA ARE ARE NOT ATTACHED

28. CONTRACTOR IS REQUIRED TO SIGN THIS DOCUMENT AND RETURN _ __ COPIES

TO ISSUING OFFICE. CONTRACTOR AGREES TO FURNISH AND DELIVER ALL ITEMS

SET FORTH OR OTHERWISE IDENTIFIED ABOVE AND ON ANY ADDITIONAL SHEETS

SUBJECT TO THE TERMS AND CONDITIONS SPECIFIED HEREIN.

29. AWARD OF CONTRACT: REF. _ _______________ OFFER DATED

_ __________. YOUR OFFER ON SOLICITATION (BLOCK 5), INCLUDING ANY

ADDITIONS OR CHANGES WHICH ARE SET FORTH HEREIN, IS ACCEPTED AS

TO ITEMS:

30a. SIGNATURE OF OFFEROR/CONTRACTOR 31a. UNITED STATES OF AMERICA (SIGNATURE OF CONTRACTING OFFICER)

30b. NAME AND TITLE OF SIGNER (Type or print) 30c. DATE SIGNED 31b. NAME OF CONTRACTING OFFICER (Type or print) 31c. DATE SIGNED

ITEM NO. 20.

SCHEDULE OF SUPPLIES/SERVICES

21.

QUANTITY

22.

UNIT

23.

UNIT PRICE

24.

AMOUNT

32a. QUANTITY IN COLUMN 21 HAS BEEN

RECEIVED INSPECTED ACCEPTED, AND CONFORMS TO THE CONTRACT, EXCEPT AS NOTED: _______________________________

32b. SIGNATURE OF AUTHORIZED GOVERNMENT

REPRESENTATIVE

32c. DATE 32d. PRINTED NAME AND TITLE OF AUTHORIZED GOVERNMENT

REPRESENTATIVE

32e. MAILING ADDRESS OF AUTHORIZED GOVERNMENT REPRESENTATIVE 32f. TELEPHONE NUMBER OF AUTHORIZED GOVERNMENT REPRESENTATIVE

32g. E-MAIL OF AUTHORIZED GOVERNMENT REPRESENTATIVE

33. SHIP NUMBER 34. VOUCHER NUMBER 35. AMOUNT VERIFIED

CORRECT FOR

36. PAYMENT 37. CHECK NUMBER

PARTIAL FINAL COMPLETE PARTIAL FINAL

38. S/R ACCOUNT NO. 39. S/R VOUCHER NO. 40. PAID BY

41.a. I CERTIFY THIS ACCOUNT IS CORRECT AND PROPER FOR PAYMENT 42a. RECEIVED BY (Print) 41b. SIGNATURE AND TITLE OF CERTIFYING OFFICER 41C. DATE

42b. RECEIVED AT (Location)

42c. DATE REC’D (YY/MM/DD) 42d. TOTAL CONTAINERS

STANDARD FORM 1449 (REV. 2/2012) BACK

TABLE OF CONTENTS

SECTION 1 - THE SCHEDULE

* SF 1449 cover sheet

* Continuation To SF-1449, RFP Number 19GT5025R0004, Prices, Block 23

* Continuation To SF-1449, RFP Number 19GT5025R0004, Schedule of Supplies/Services, Block 20

Description/Specifications/Work Statement

* Attachment 1 CYBERSECURITY SUPPLY CHAIN RISK MANAGEMENT (C-SCRM) SOFTWARE

PRODUCER ATTESTATION FORM

SECTION 2 - CONTRACT CLAUSES

* Contract Clauses

* Addendum to Contract Clauses - FAR and DOSAR Clauses not Prescribed in Part 12

SECTION 3 - SOLICITATION PROVISIONS

* Solicitation Provisions

* Addendum to Solicitation Provisions - FAR and DOSAR Provisions not Prescribed in Part 12

SECTION 4 - EVALUATION

* Evaluation

* Addendum to Evaluation - FAR and DOSAR Provisions not Prescribed in Part 12

SECTION 5 - OFFEROR REPRESENTATIONS AND CERTIFICATIONS

* Offeror Representations and Certifications

* Addendum to Offeror Representations and Certifications - FAR and DOSAR Provisions not

Prescribed in Part 12

SECTION 1 - THE SCHEDULE

CONTINUATION TO SF-1449, RFP NUMBER 19GT5025R0004, PRICES BLOCK 23

I. SCOPE OF SERVICES

The purpose of this solicitation is the acquisition of main internet circuit services for the US Embassy Compound, located in Zone 16 in Guatemala City, Guatemala including all pathways, conductors, equipment, labor, materials and installation to provide fiber telecom distribution as described herein.

The Contractor shall complete all work, including furnishing all labor, material, equipment, and services, unless otherwise specified herein, required under this contract for stated services within the time specified herein. The price listed below shall include all labor, materials, overhead, and profit. In consideration of satisfactory performance of all scheduled services required under this contract, the Contractor shall be paid firm fixed prices for all services.

II. PRICING

The Contractor shall furnish all engineering, labor, tools, equipment, materials, supplies and services to provide the required circuit as specified under Section 1, hereof.

The contract will be for a one-year period from the date of the contract award.

In consideration of satisfactory performance of the services required under this contract, the Contractor shall be paid a firm fixed price (FFP) per month as stated in the schedule below. Offers shall be in Quetzales or U.S. Dollars, depending on the Contractor´s capacity to provide an invoice in the currency proposal was submitted. However, the currency awarded in the contract will remain throughout the performance period of the contract.

2.1 VALUE ADDED TAX

Value Added Tax (VAT) is not included in the CLIN rates. Instead, it shall be included in invoices submitted for payment and an IVA form will be provided for 12% tax.

2.2 PRICING - INDICATE THE CURRENCY OF PAYMENT

LINE

ITEM DESCRIPTION OF SERVICES MONTHS

UNIT PRICE

(NET)

TOTAL FIRM

FIXED PRICE

(NET)

INTERNET CIRCUIT– US Embassy – Guatemala - Dedicated Internet Network for NEC at Boulevard Austriaco 11-51, Zona 16. 12-pair primary circuit at minimum 700Mbps as detailed in SOW.

INTERNET CIRCUIT– US Embassy – Guatemala - Dedicated Internet Network for NEC at Boulevard Austriaco 11-51, Zona 16. 12-pair secondary circuit at minimum 700Mbps for redundancy, as detailed in SOW.

3 Installation 1 4 Defense Base Act (Insurance) 1

GRAND TOTAL (NET)

III. QUALITY ASSURANCE AND SURVEILLANCE PLAN (QASP)

This plan provides an effective method to promote satisfactory contractor performance. The QASP provides a method for the Contracting Officer's Representative (COR) to monitor Contractor performance, advise the Contractor of unsatisfactory performance, and notify the Contracting Officer of continued unsatisfactory performance. The Contractor, not the Government, is responsible for management and quality control to meet the terms of the contract. The role of the Government is to monitor quality to ensure that contract standards are achieved.

Performance objective Scope of work paragraphs Performance Threshold Services Performs all main internet circuit services set forth in the scope of work.

1. thru 11.

All required services are performed and no more than one (1) customer complaint is received per month.

1. SURVEILLANCE. The COR will receive and document all complaints from Government personnel regarding the services provided. If appropriate, the COR will send the complaints to the Contractor for corrective action.

2. STANDARD. The performance standard is that the Government receives no more than one (1) [Note to Contracting Officer: Insert other number if desired] customer complaint per month. The COR shall notify the Contracting Officer of the complaints so that the Contracting Officer may take appropriate action to enforce the inspection clause (FAR 52.212.4, Contract Terms and Conditions-Commercial Items (May 2001), if any of the services exceed the standard.

3. PROCEDURES.

a. If any Government personnel observe unacceptable services, either incomplete work or required services not being performed they should immediately contact the COR.

b. The COR will complete appropriate documentation to record the complaint.

c. If the COR determines the complaint is invalid, the COR will advise the complainant.

The COR will retain the annotated copy of the written complaint for his/her files.

d. If the COR determines the complaint is valid, the COR will inform the Contractor and give the

Contractor additional time to correct the defect, if additional time is available. The COR shall determine how much time is reasonable.

e. The COR shall, as a minimum, orally notify the Contractor of any valid complaints.

f. If the Contractor disagrees with the complaint after investigation of the site and challenges the validity of the complaint, the Contractor will notify the COR. The COR will review the matter to determine the validity of the complaint.

g. The COR will consider complaints as resolved unless notified otherwise by the complainant.

h. Repeat customer complaints are not permitted for any services. If a repeat customer complaint is received for the same deficiency during the service period, the COR will contact the Contracting Officer for appropriate action under the Inspection clause.

CONTINUATION TO SF-1449, RFP NUMBER 19GT5025R0004

SCHEDULE OF SUPPLIES/SERVICES, BLOCK 20

DESCRIPTION/SPECIFICATIONS/WORK STATEMENT

I. SCOPE OF WORK

The U.S. Embassy in Guatemala issues a solicitation for provision of main internet circuit services for the Embassy Compound, located in Zone 16 in Guatemala City, Guatemala including all pathways, conductors, equipment, labor, materials and installation to provide fiber distribution as described herein from the Internet Service Provider (ISP).

This internet circuit shall be high-end, professional grade service that differs from the residential, dial up service. Dedicated (not shared or bundled) Internet Bandwidth, 24/7, “always-on” with unlimited usage is required. Fiber optic, terrestrial connectivity is preferred.

The local ISP access circuit to the US Embassy in Guatemala must meet the following specifications/requirements for connectivity:

1. A /28 subnet static Public IP addresses for VPN equipment, network mask, and default gateway IP address.

2. ISP interface connectors: LC fiber connector (MM-multimode) – Gigabit interface

3. ISP availability: "Always on"

4. ISP connection: IPs must NOT repeat and NOT use Network Address Translation (NAT).

5. ISP must permit all IP protocols (including but not limited to ICMP, UDP, TCP, and IPSEC) to transit without filters or proxies. Unfiltered access to the Internet is required without ISP firewall blocking or stateful inspection.

6. ISP must permit installation of Customer VPN encryption devices on circuit.

7. ISP must permit ping and trace route traffic from 169.252.0.0/16 and 169.253.0.0/16 to the ISP connection (LC fiber Gigabit MM router interface which terminates Customer VPN encryption device).

8. High quality performance, the following parameters in a vendor’s Service Level Agreement (SLA) should be used:

a. Packet Loss <=.5%

b. Availability of 99.9%.

9. Prospective Offeror must not have ZTE, Huawei, Xiaomi and affiliated branded products in use on the internet connection. The US Embassy in Guatemala may not enter contract (or extend or renew contract) with an entity that uses above mentioned equipment, system, or service that uses covered telecommunications equipment or services as a substantial or essential component of any system, or as critical technology as part of any system. The ISP shall describe what network switching/connectivity equipment they use in their infrastructure, and if there is an option to use a path without the equipment mentioned above.

Fiber Telecom statement of work follows:

1. Provide connections and service provisioned from the nearest two Central Offices (CO) to provide communications for the New Embassy Compound. Install and terminate all service provider equipment and cables within a designated Embassy Compound telecommunications services entrance facility (TSEF). TSEF is the demarcation room (demark) located along Boulevard Austriaco

11-51, Zona 16, Guatemala City, Guatemala. All cables must enter the TSEF via pathways below grade from a telecom manhole. The US Government (USG) shall provide the telecom manhole and below grade duct bank from the telecom manhole into the demark.

2. Provide and install 12-strand fiber optic cable (Primary) capable of unrestricted Internet access of up to 700Mpbs.

3. Provide and install 12-strand fiber optic cable (Secondary) capable of unrestricted Internet access of up to 700Mpbs.

4. Service to the Embassy must support 99.9% uptime or better, meaning in any given month (43,200 minutes), total downtime must be less than 43 minutes. Failover between the primary and secondary fiber circuits and their services must be transparent to the customer unless the failure occurs in the Embassy’s demark. Service Provider must provide CPE redundancy to mitigate failures at the demarcation. This should include any routers, switches, gateways and uninterrupted backup power units.

5. The primary and secondary fiber circuits must enter the telecom manhole from opposite directions to mitigate risk of common failure. A microwave shot is not acceptable to meet this requirement.

Vendor must provide documentation showing mean time to repair (MTTR), and mean time between failures (MTBF) for the Municipal Area Networks (MAN) rings used. Real world case studies from Guatemala are highly desirable.

6. Proposal must include a map showing routing of infrastructure from central office point of origin to the TSEF.

7. All cabling installation must conform to ANSI/EIA/TIA wiring standards.

8. Provide and install an enterprise level fiber muxing device with a spare readily available locally in Guatemala. By way of example, the mux must meet or exceed the specifications of the 16 port Optimux FiberMux.

9. A level of service requiring specific response times on 24 Hour, 7 days a week basis as well as break/ fix timelines is required.

ATTACHMENT 1

INSTRUCTIONS

Version 1.0

"C-SCRM QUESTIONNAIRE" EXCEL WORKSHEET COMPLETION INSTRUCTIONS:

● This worksheet shall be completed by the vendor responsible for submitting the offer. References to "organization" refer to the offering entity. If the offering entity is a joint venture (JV), the response may come from either the JV or from the JV managing partner.

● Provide the requested inputs in the gray shaded lines of the template under column D, Vendor Response, for all Items Numbers for Sections 1-3. Offerors are advised that the Government may request documentation from the Offerors to validate the responses provided.

"SOFTWARE PRODUCER ATTESTATION" EXCEL WORKSHEET COMPLETION INSTRUCTIONS:

● NIST White Paper "Definition of Critical Software Under Executive Order (EO) 14028" dated October 13, 2021 defines critical software. Complete this worksheet by providing the requested inputs in the gray shaded lines of the template under columns C-D if your firm or your subcontractors are offering to supply critical software to the Government as part of your firm's offer. This worksheet must be completed by each software producer that will be supplying critical software as part of your firm's offer.

If critical software is not being provided by your firm or subcontractors, please enter N/A in said gray shaded lines of the template.

CYBERSECURITY SUPPLY CHAIN RISK MANAGEMENT (C-SCRM) QUESTIONNAIRE

SECTION 1 - CONTACT INFORMATION

ITEM

NO. ITEM DESCRIPTION VENDOR

RESPONSE

1.1 Enter the name of your company.

1.2 Enter the name of the primary Point-Of-Contact (POC) for your company that the Government may contact to discuss the vendor inputs on this questionnaire.

1.3 Enter the job title of the primary POC.

1.4 Enter the phone number of the primary POC in the following format: (555) 555-5555

1.5 Enter the e-mail address of the primary POC.

SECTION 2 VENDOR RISK MANAGEMENT PLAN

ITEM

NO. ITEM DESCRIPTION VENDOR

RESPONSE

NIST SP

800-53 Reference

2.1 Does your organization identify its key supply chain threats? IR-8, SR-7

2.2 Does your organization map key suppliers to your supply chain threats?

IR-8, SR-7

2.3 Do you have a policy or process to ensure that none of your suppliers or third-party components have an active exclusion record in the System for Award Management (https://sam.gov)?

SAM.gov

2.4 Does your organization have written SCRM requirements in

contracts with your key suppliers?

SA-4

2.5 Does your organization verify that your suppliers meet SCRM requirements through contractual terms and conditions?

SR-6

SECTION 3 PHYSICAL AND PERSONNEL SECURITY

ITEM

NO. ITEM DESCRIPTION VENDOR

RESPONSE

NIST SP

800-53 Reference

3.1 Does your organization have policies for conducting background checks of your employees as permitted by the country in which your organization operates?

PE-2, PE-3

PS-3

3.2 Does your organization have procedures in place to prevent tampering of Information and Communications Technology (ICT) equipment stored as supply chain inventory?

SR-9

AC-1

3.3 Do you provide literacy training on recognizing and reporting potential indicators of insider threat?

AT-2(2)

CYBERSECURITY SUPPLY CHAIN RISK MANAGEMENT (C-SCRM) SOFTWARE PRODUCER

ATTESTATION FORM

This form must be completed by the software producer.

ITEM NUMBER ITEM DESCRIPTION VENDOR RESPONSE

1.1 Enter the name of the software

producer.

1.2 Provide a statement attesting

that the software products listed in Item Number 1.3 of this form follow the secure development "practices" and "tasks" identified in NIST SP 800-

218. A summary of these practices and tasks are provided below for reference from NIST

SP 800-218. If you cannot attest to all practices and tasks, identify the ones that you attest to and the ones that you cannot attest to. For those practices and tasks that you cannot attest to, describe the practices that you have in place to mitigate those risks (i.e., risks for practices or tasks you cannon attest to), and provide a Plan of Action & Milestones (POA&M) detailing how your firm will reach compliance for those non-compliant practices and tasks.

1.3 A description of which product

or products the statement provided for Item Number 1.2 refers to (preferably focused at the company or product line level and inclusive of all unclassified products sold to Federal agencies).

NIST SP 800-218, Table 1: The Secure Software Development Framework (SSDF) Version 1.1 Practices Tasks Notional

Implementation Examples

References

Define Security Requirements for

Software Development

(PO.1): Ensure that security requirements for software development are known at all times so that they can be taken into account throughout the SDLC and duplication of effort can be minimized because the requirements information can be collected once and shared. This includes requirements from internal sources (e.g., the organization’s policies, business objectives, and risk management strategy) and external sources (e.g., applicable laws and regulations).

PO.1.1: Identify and document all security requirements for the organization’s software development infrastructures and processes, and maintain the requirements over time.

Example 1: Define policies for securing software development infrastructures and their components, including development endpoints, throughout the

SDLC and maintaining that security.

BSAFSS: SM.3, DE.1,

IA.1, IA.2

Example 2: Define policies for securing software development processes throughout the

SDLC and maintaining that security, including for open-source and other third-party software components utilized by software being developed.

BSIMM: CP1.1,

CP1.3, SR1.1, SR2.2,

SE1.2, SE2.6

Example 3: Review and update security requirements at least annually, or sooner if there are new requirements from internal or external sources, or a major security incident targeting software development infrastructure has occurred.

EO14028: 4e(ix)

Example 4: Educate affected individuals on impending

IEC62443: SM-7, SM-

changes to requirements.

NISTCSF: ID.GV-3

OWASPASVS: 1.1.1

OWASPMASVS: 1.10

OWASPSAMM: PC1-

A, PC1-B, PC2-A

PCISSLC: 2.1, 2.2

SCFPSSD: Planning the Implementation and Deployment of

Secure Development Practices

SP80053: SA-1, SA-8,

SA-15, SR-3

SP800160: 3.1.2,

3.2.1, 3.2.2, 3.3.1, 3.4.2, 3.4.3

SP800161: SA-1, SA-

8, SA-15, SR-3

SP800181: T0414;

K0003, K0039, K0044, K0157, K0168, K0177, K0211, K0260, K0261, K0262, K0524; S0010, S0357, S0368; A0033, A0123, A0151

PO.1.2: Identify and document all security requirements for organization-developed software to meet, and maintain the requirements over time.

Example 1: Define policies that specify risk-based software architecture and design requirements, such as making code modular to facilitate code reuse and updates;

isolating security components from other components during execution;

avoiding undocumented commands and

BSAFSS: SC.1-1, SC.2,

PD.1-1, PD.1-2, PD.1-

3, PD.2-2, SI, PA, CS,

AA, LO, EE

settings; and providing features that will aid software acquirers with the secure deployment, operation, and maintenance of the software.

Example 2: Define policies that specify the security requirements for the organization’s software, and verify compliance at key points in the SDLC (e.g., classes of software flaws verified by gates, responses to vulnerabilities discovered in released software).

BSIMM: SM1.1,

SM1.4, SM2.2, CP1.1,

CP1.2, CP1.3, CP2.1,

CP2.3, AM1.2,

SFD1.1, SFD2.1,

SFD3.2, SR1.1, SR1.3,

SR2.2, SR3.3, SR3.4

Example 3: Analyze the risk of applicable technology stacks (e.g., languages, environments, deployment models), and recommend or require the use of stacks that will reduce risk compared to others.

EO14028: 4e(ix)

Example 4: Define policies that specify what needs to be archived for each software release (e.g., code, package files, third-party libraries, documentation, data inventory)

IEC62443: SR-3, SR-4,

SR-5, SD-4

and how long it needs to be retained based on the SDLC model, software end-of-life, and other factors.

Example 5: Ensure that policies cover the entire software life cycle, including notifying users of the impending end of software support and the date of software end-of-life.

ISO27034: 7.3.2

Example 6: Review all security requirements at least annually, or sooner if there are new requirements from internal or external sources, a major vulnerability is discovered in released software, or a major security incident targeting organization-developed software has occurred.

MSSDL: 2, 5

Example 7:

Establish and follow processes for handling requirement exception requests, including periodic reviews of all approved exceptions.

NISTCSF: ID.GV-3

OWASPMASVS: 1.12

OWASPSAMM: PC1-

A, PC1-B, PC2-A, PC3-

A, SR1-A, SR1-B, SR2-

B, SA1-B, IR1-A

PCISSLC: 2.1, 2.2, 2.3,

3.3

SCFPSSD: Establish Coding Standards and Conventions

SP80053: SA-8, SA-

8(3), SA-15, SR-3

SP800160: 3.1.2,

3.2.1, 3.3.1

SP800161: SA-8, SA-

15, SR-3

SP800181: T0414;

K0003, K0039, K0044, K0157, K0168, K0177, K0211, K0260, K0261, K0262, K0524; S0010, S0357, S0368; A0033, A0123, A0151

PO.1.3: Communicate requirements to all third parties who will provide commercial software components to the organization for reuse by the organization’s own software.

[Formerly PW.3.1]

Example 1: Define a core set of security requirements for software components, and include it in acquisition documents, software contracts, and other agreements with third parties.

BSAFSS: SM.1, SM.2,

SM.2-1, SM.2-4

Example 2: Define security-related criteria for selecting software;

the criteria can include the third party’s vulnerability disclosure program and product security incident response

BSIMM: CP2.4,

CP3.2, SR2.5, SR3.2

capabilities or the third party’s adherence to organization-defined practices.

Example 3: Require third parties to attest that their software complies with the organization’s security requirements.

EO14028: 4e(vi), 4e(ix)

Example 4: Require third parties to provide provenance data and integrity verification mechanisms for all components of their software.

IDASOAR: 19, 21

Example 5:

Establish and follow processes to address risk when there are security requirements that third-party software components to be acquired do not meet; this should include periodic reviews of all approved exceptions to requirements.

IEC62443: SM-9, SM-

MSSDL: 7

NISTCSF: ID.SC-3

OWASPSAMM: SR3-

A SCAGILE: Tasks

Requiring the Help of Security Experts 8

SCFPSSD: Manage Security Risk

Inherent in the Use of Third-Party Components

SCSIC: Vendor Sourcing Integrity

Controls

SP80053: SA-4, SA-9,

SA-10, SA-10(1), SA-

15, SR-3, SR-4, SR-5

SP800160: 3.1.1,

3.1.2

SP800161: SA-4, SA-

9, SA-9(1), SA-9(3),

SA-10, SA-10(1), SA-

15, SR-3, SR-4, SR-5

SP800181: T0203,

T0415; K0039;

S0374; A0056, A0161 Implement Roles and Responsibilities (PO.2): Ensure that everyone inside and outside of the organization involved in the SDLC is prepared to perform their SDLC-related roles and responsibilities throughout the

SDLC.

PO.2.1: Create new roles and alter responsibilities for existing roles as needed to encompass all parts of the SDLC.

Periodically review and maintain the defined roles and responsibilities, updating them as needed.

Example 1: Define SDLC-related roles and responsibilities for all members of the software development team.

BSAFSS: PD.2-1,

PD.2-2

Example 2:

Integrate the security roles into the software development team.

BSIMM: SM1.1,

SM2.3, SM2.7, CR1.7

Example 3: Define roles and responsibilities for cybersecurity staff, security champions, project managers and leads, senior management, software developers, software testers, software assurance leads and staff, product owners, operations and

EO14028: 4e(ix) platform engineers, and others involved in the SDLC.

Example 4:

Conduct an annual review of all roles and responsibilities.

IEC62443: SM-2, SM-

Example 5: Educate affected individuals on impending changes to roles and responsibilities, and confirm that the individuals understand the changes and agree to follow them.

NISTCSF: ID.AM-6,

ID.GV-2

Example 6:

Implement and use tools and processes to promote communication and engagement among individuals with SDLC-related roles and responsibilities, such as creating messaging channels for team discussions.

PCISSLC: 1.2

Example 7:

Designate a group of individuals or a team as the code owner for each project.

SCSIC: Vendor Software

Development Integrity Controls

SP80053: SA-3

SP800160: 3.2.1,

3.2.4, 3.3.1

SP800161: SA-3

SP800181: K0233

PO.2.2: Provide role-based training for all personnel with responsibilities that contribute to secure development.

Periodically review personnel proficiency and role-based training, and update the training as needed.

Example 1:

Document the desired outcomes of training for each role.

BSAFSS: PD.2-2

Example 2: Define the type of training or curriculum required to achieve the desired outcome for each role.

BSIMM: T1.1, T1.7,

T1.8, T2.5, T2.8, T2.9, T3.1, T3.2, T3.4

Example 3: Create a training plan for each role.

EO14028: 4e(ix)

Example 4: Acquire or create training for each role;

acquired training may need to be customized for the organization.

IEC62443: SM-4

Example 5:

Measure outcome performance to identify areas where changes to training may be beneficial.

MSSDL: 1

NISTCSF: PR.AT

OWASPSAMM: EG1-

A, EG2-A

PCISSLC: 1.3

SCAGILE:

Operational Security Tasks 14, 15; Tasks

Requiring the Help of Security Experts 1

SCFPSSD: Planning the Implementation and Deployment of

Secure Development Practices

SCSIC: Vendor Software

Development Integrity Controls

SP80053: SA-8

SP800160: 3.2.4,

3.2.6

SP800161: SA-8

SP800181: OV-TEA-

001, OV-TEA-002;

T0030, T0073, T0320; K0204, K0208, K0220, K0226, K0243, K0245, K0252;

S0100, S0101;

A0004, A0057

PO.2.3: Obtain upper management or authorizing official commitment to secure development, and convey that commitment to all with development-related roles and responsibilities.

Example 1: Appoint a single leader or leadership team to be responsible for the entire secure software development process, including being accountable for releasing software to production and delegating responsibilities as appropriate.

BSIMM: SM1.3,

SM2.7, CP2.5

Example 2:

Increase authorizing officials’ awareness of the risks of developing software without integrating security throughout the development life cycle and the risk mitigation provided by secure development practices.

EO14028: 4e(ix)

Example 3: Assist upper management in incorporating

NISTCSF: ID.RM-1,

ID.SC-1

secure development support into their communications with personnel with development-related roles and responsibilities.

Example 4: Educate all personnel with development-related roles and responsibilities on upper management’s commitment to secure development and the importance of secure development to the organization.

OWASPSAMM:

SM1.A

PCISSLC: 1.1

SP800181: T0001,

T0004 Implement Supporting

Toolchains (PO.3):

Use automation to reduce human effort and improve the accuracy, reproducibility, usability, and comprehensiveness of security practices throughout the SDLC, as well as provide a way to document and demonstrate the use of these practices.

Toolchains and tools may be used at different levels of the organization, such as

PO.3.1: Specify which tools or tool types must or should be included in each toolchain to mitigate identified risks, as well as how the toolchain components are to be integrated with each other.

Example 1: Define categories of toolchains, and specify the mandatory tools or tool types to be used for each category.

BSIMM: CR1.4,

ST1.4, ST2.5, SE2.7

Example 2: Identify security tools to integrate into the developer toolchain.

CNCFSSCP: Securing Materials—

Verification; Securing Build Pipelines—

Verification, Automation, Secure Authentication/Acce ss; Securing Artefacts—

Verification; Securing Deployments—

Verification Example 3: Define what information is EO14028: 4e(iii), 4e(ix) organization-wide or project-specific, and may address a particular part of the

SDLC, like a build pipeline.

to be passed between tools and what data formats are to be used.

Example 4:

Evaluate tools’ signing capabilities to create immutable records/logs for auditability within the toolchain.

MSSDL: 8

Example 5: Use automated technology for toolchain management and orchestration.

OWASPSAMM: IR2-

B, ST2-B

SCAGILE: Tasks Requiring the Help of

Security Experts 9 SCSIC: Vendor

Software Delivery Integrity Controls

SP80053: SA-15

SP800161: SA-15

SP800181: K0013,

K0178 PO.3.2: Follow recommended security practices to deploy, operate, and maintain tools and toolchains.

Example 1:

Evaluate, select, and acquire tools, and assess the security of each tool.

BSAFSS: DE.2

Example 2:

Integrate tools with other tools and existing software development processes and workflows.

BSIMM: SR1.1,

SR1.3, SR3.4

Example 3: Use code-based configuration for toolchains (e.g., pipelines-as-code, toolchains-as-code).

CNCFSSCP: Securing Build Pipelines—

Verification, Automation, Controlled

Environments, Secure

Authentication/Acce ss; Securing Artefacts— Verification, Automation, Controlled

Environments, Encryption; Securing

Deployments— Verification, Automation

Example 4:

Implement the technologies and processes needed for reproducible builds.

EO14028: 4e(i)(F), 4e(ii), 4e(iii), 4e(v), 4e(vi), 4e(ix)

Example 5: Update, upgrade, or replace tools as needed to address tool vulnerabilities or add new tool capabilities.

IEC62443: SM-7

Example 6:

Continuously monitor tools and tool logs for potential operational and security issues, including policy violations and anomalous behavior.

IR8397: 2.2

Example 7:

Regularly verify the integrity and check the provenance of each tool to

OWASPASVS: 1.14.3,

1.14.4, 14.1, 14.2 identify potential problems.

Example 8: See PW.6 regarding compiler, interpreter, and build tools.

OWASPMASVS: 7.9

Example 9: See PO.5 regarding implementing and maintaining secure environments.

OWASPSCVS: 3, 5

SCAGILE: Tasks Requiring the Help of

Security Experts 9 SCFPSSD: Use

Current Compiler and Toolchain

Versions and Secure Compiler Options

SCSIC: Vendor Software Delivery Integrity Controls

SP80053: SA-15

SP800161: SA-15

SP800181: K0013,

K0178 PO.3.3: Configure tools to generate artifacts of their support of secure software development practices as defined by the organization.

Example 1: Use existing tooling (e.g., workflow tracking, issue tracking, value stream mapping) to create an audit trail of the secure development-related actions that are performed for continuous improvement purposes.

BSAFSS: PD.1-5

Example 2:

Determine how often the collected information should be audited, and implement the

BSIMM: SM1.4,

SM3.4, SR1.3

necessary processes.

Example 3:

Establish and enforce security and retention policies for artifact data.

CNCFSSCP: Securing Build Pipelines—

Verification, Automation, Controlled

Environments;

Securing Artefacts—

Verification Example 4: Assign responsibility for creating any needed artifacts that tools cannot generate.

EO14028: 4e(i)(F), 4e(ii), 4e(v), 4e(ix)

IEC62443: SM-12, SI-

MSSDL: 8

OWASPSAMM: PC3-

B

OWASPSCVS: 3.13,

3.14

PCISSLC: 2.5

SCAGILE: Tasks

Requiring the Help of Security Experts 9

SCSIC: Vendor Software Delivery Integrity Controls

SP80053: SA-15

SP800161: SA-15

SP800181: K0013;

T0024 Define and Use

Criteria for Software Security Checks

(PO.4): Help ensure that the software resulting from the

SDLC meets the organization’s expectations by defining and using criteria for checking the software’s

PO.4.1: Define criteria for software security checks and track throughout the SDLC.

Example 1: Ensure that the criteria adequately indicate how effectively security risk is being managed.

BSAFSS: TV.2-1,

TV.5-1

Example 2: Define key performance indicators (KPIs), key risk indicators (KRIs), vulnerability

BSIMM: SM1.4,

SM2.1, SM2.2,

SM2.6, SM3.3, CP2.2

security during development.

severity scores, and other measures for software security.

Example 3: Add software security criteria to existing checks (e.g., the

Definition of Done in agile SDLC methodologies).

EO14028: 4e(iv), 4e(v), 4e(ix)

Example 4: Review the artifacts generated as part of the software development workflow system to determine if they meet the criteria.

IEC62443: SI-1, SI-2,

SVV-3

Example 5: Record security check approvals, rejections, and exception requests as part of the workflow and tracking system.

ISO27034: 7.3.5

Example 6: Analyze collected data in the context of the security successes and failures of each development project, and use the results to improve the SDLC.

MSSDL: 3

OWASPSAMM: PC3-

A, DR3-B, IR3-B, ST3-

B

PCISSLC: 3.3

SP80053: SA-15, SA-

15(1)

SP800160: 3.2.1,

3.2.5, 3.3.1

SP800161: SA-15, SA-

15(1)

SP800181: K0153,

K0165

PO.4.2: Implement processes, mechanisms, etc. to gather and safeguard the necessary information in support of the criteria.

Example 1: Use the toolchain to automatically gather information that informs security decision-making.

BSAFSS: PD.1-4,

PD.1-5

Example 2: Deploy additional tools if needed to support the generation and collection of information supporting the criteria.

BSIMM: SM1.4,

SM2.1, SM2.2, SM3.4

Example 3:

Automate decision-making processes utilizing the criteria, and periodically review these processes.

EO14028: 4e(iv), 4e(v), 4e(ix)

Example 4: Only allow authorized personnel to access the gathered information, and prevent any alteration or deletion of the information.

IEC62443: SI-1, SVV-

1, SVV-2, SVV-3, SVV-

OWASPSAMM: PC3-

B

PCISSLC: 2.5

SCSIC: Vendor

Software Delivery Integrity Controls

SP80053: SA-15, SA-

15(1), SA-15(11)

SP800160: 3.2.5,

3.3.7

SP800161: SA-15, SA-

15(1), SA-15(11)

SP800181: T0349;

K0153

Implement and Maintain Secure Environments for

Software Development

(PO.5): Ensure that all components of the environments for software development are strongly protected from internal and external threats to prevent compromises of the environments or the software being developed or maintained within them. Examples of environments for software development include development, build, test, and distribution environments.

PO.5.1: Separate and protect each environment involved in software development.

Example 1: Use multi-factor, risk-based authentication and conditional access for each environment.

BSAFSS: DE.1, IA.1,

IA.2

Example 2: Use network segmentation and access controls to separate the environments from each other and from production environments, and to separate components from each other within each non-production environment, in order to reduce attack surfaces and attackers’ lateral movement and privilege/access escalation.

CNCFSSCP: Securing Build Pipelines—

Controlled Environments

Example 3: Enforce authentication and tightly restrict connections entering and exiting each software development environment, including minimizing access to the internet to only what is necessary.

EO14028: 4e(i)(A), 4e(i)(B), 4e(i)(C), 4e(i)(D), 4e(i)(F), 4e(ii), 4e(iii), 4e(v), 4e(vi), 4e(ix)

Example 4:

Minimize direct human access to toolchain systems, IEC62443: SM-7 such as build services.

Continuously monitor and audit all access attempts and all use of privileged access.

Example 5:

Minimize the use of production-environment software and services from non-production environments.

NISTCSF: PR.AC-5,

PR.DS-7

Example 6:

Regularly log, monitor, and audit trust relationships for authorization and access between the environments and between the components within each environment.

SCAGILE: Tasks Requiring the Help of Security Experts 11

Example 7:

Continuously log and monitor operations and alerts across all components of the development environment to detect, respond, and recover from attempted and actual cyber incidents.

SCSIC: Vendor Software Delivery Integrity Controls

Example 8:

Configure security controls and other tools involved in separating and protecting the environments to generate artifacts for their activities.

SP80053: SA-3(1),

SA-8, SA-15

Example 9:

Continuously monitor all software deployed in each environment for new vulnerabilities, and respond to vulnerabilities appropriately following a risk-based approach.

SP800161: SA-3, SA-

8, SA-15

Example 10:

Configure and implement measures to secure the environments’ hosting infrastructures following a zero trust architecture.

SP800181: OM-NET-

001, SP-SYS-001;

T0019, T0023, T0144, T0160, T0262, T0438, T0484, T0485, T0553; K0001, K0005, K0007, K0033, K0049, K0056, K0061, K0071, K0104, K0112, K0179, K0326, K0487;

S0007, S0084, S0121;

A0048

PO.5.2: Secure and harden development endpoints (i.e., endpoints for software designers, developers, testers, builders, etc.) to perform development-related tasks using a risk-based approach.

Example 1:

Configure each development endpoint based on approved hardening guides, checklists, etc.; for example, enable FIPS-compliant encryption of all sensitive data at rest and in transit.

BSAFSS: DE.1-1, IA.1,

IA.2

Example 2:

Configure each development endpoint and the development resources to provide the least functionality needed by users and services and to

EO14028: 4e(i)(C), 4e(i)(E), 4e(i)(F), 4e(ii), 4e(iii), 4e(v), 4e(vi), 4e(ix) enforce the principle of least privilege.

Example 3:

Continuously monitor the security posture of all development endpoints, including monitoring and auditing all use of privileged access.

IEC62443: SM-7

Example 4:

Configure security controls and other tools involved in securing and hardening development endpoints to generate artifacts for their activities.

NISTCSF: PR.AC-4,

PR.AC-7, PR.IP-1,

PR.IP-3, PR.IP-12,

PR.PT-1, PR.PT-3,

DE.CM

Example 5: Require multi-factor authentication for all access to development endpoints and development resources.

SCAGILE: Tasks Requiring the Help of Security Experts 11

Example 6: Provide dedicated development endpoints on non-production networks for performing all development-related tasks.

Provide separate endpoints on production networks for all other tasks.

SCSIC: Vendor Software Delivery Integrity Controls

Example 7:

Configure each

SP80053: SA-15

development endpoint following a zero trust architecture.

SP800161: SA-15

SP800181: OM-ADM-

001, SP-SYS-001;

T0484, T0485, T0489, T0553; K0005, K0007, K0077, K0088, K0130, K0167, K0205, K0275; S0076, S0097, S0121, S0158; A0155

Protect All Forms of Code from

Unauthorized Access and

Tampering (PS.1):

Help prevent unauthorized changes to code, both inadvertent and intentional, which could circumvent or negate the intended security characteristics of the software. For code that is not intended to be publicly accessible, this helps prevent theft of the software and may make it more difficult or time-consuming for attackers to find vulnerabilities in the software.

PS.1.1: Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc.

have access.

Example 1: Store all source code and configuration-as-code in a code repository, and restrict access to it based on the nature of the code.

For example, open-source code intended for public access may need its integrity and availability protected; other code may also need its confidentiality protected.

BSAFSS: IA.1, IA.2,

SM.4-1, DE.1-2

Example 2: Use version control features of the repository to track all changes made to the code with accountability to the individual account.

BSIMM: SE2.4

Example 3: Use commit signing for code repositories.

CNCFSSCP: Securing the Source Code—

Verification, Automation, Controlled

Environments, Secure

Authentication;

Securing Materials—

Automation Example 4: Have the code owner review and approve all changes made to the code by others.

EO14028: 4e(iii), 4e(iv), 4e(ix)

Example 5: Use code signing to help protect the integrity of executables.

IDASOAR: Fact Sheet

Example 6: Use cryptography (e.g., cryptographic hashes) to help protect file integrity.

IEC62443: SM-6, SM-

7, SM-8

NISTCSF: PR.AC-4,

PR.DS-6, PR.IP-3

OWASPASVS: 1.10,

10.3.2

OWASPMASVS: 7.1

OWASPSAMM: OE3-

B

PCISSLC: 5.1, 6.1

SCSIC: Vendor

Software Delivery Integrity Controls, Vendor Software

Development Integrity Controls

SP80053: SA-10

SP800161: SA-8, SA-

Provide a

Mechanism for Verifying Software Release Integrity

(PS.2): Help

PS.2.1: Make software integrity verification information available to software acquirers.

Example 1: Post cryptographic hashes for release files on a well-secured website.

BSAFSS: SM.4, SM.5,

SM.6

software acquirers ensure that the software they acquire is legitimate and has not been tampered with.

Example 2: Use an established certificate authority for code signing so that consumers’ operating systems or other tools and services can confirm the validity of signatures before use.

BSIMM: SE2.4

Example 3:

Periodically review the code signing processes, including certificate renewal, rotation, revocation, and protection.

CNCFSSCP: Securing Deployments—

Verification

EO14028: 4e(iii), 4e(ix), 4e(x)

IEC62443: SM-6, SM-

8, SUM-4

NISTCSF: PR.DS-6

NISTLABEL: 2.2.2.4

OWASPSAMM: OE3-

B

OWASPSCVS: 4

PCISSLC: 6.1, 6.2

SCSIC: Vendor

Software Delivery Integrity Controls

SP80053: SA-8

SP800161: SA-8

SP800181: K0178

Archive and Protect Each Software Release (PS.3):

Preserve software releases in order to help identify, analyze, and eliminate vulnerabilities

PS.3.1: Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.

Example 1: Store the release files, associated images, etc. in repositories following the organization’s established policy.

Allow read-only access to them by

BSAFSS: PD.1-5,

DE.1-2, IA.2

discovered in the software after release.

necessary personnel and no access by anyone else.

Example 2: Store and protect release integrity verification information and provenance data, such as by keeping it in a separate location from the release files or by signing the data.

CNCFSSCP: Securing Artefacts—

Automation, Controlled

Environments, Encryption; Securing

Deployments— Verification

EO14028: 4e(iii), 4e(vi), 4e(ix), 4e(x)

IDASOAR: 25

IEC62443: SM-6, SM-

NISTCSF: PR.IP-4

OWASPSCVS: 1,

3.18, 3.19, 6.3

PCISSLC: 5.2, 6.1, 6.2

SCSIC: Vendor

Software Delivery Integrity Controls

SP80053: SA-10, SA-

15, SA-15(11), SR-4

SP800161: SA-8, SA-

10, SA-15(11), SR-4

PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials

[SBOM]).

Example 1: Make the provenance data available to software acquirers in accordance with the organization’s policies, preferably using standards-based formats.

BSAFSS: SM.2

Example 2: Make the provenance data available to the organization’s operations and response teams to aid them in

BSIMM: SE3.6

mitigating software vulnerabilities.

Example 3: Protect the integrity of provenance data, and provide a way for recipients to verify provenance data integrity.

CNCFSSCP: Securing Materials— Verification, Automation

Example 4: Update the provenance data every time any of the software’s components are updated.

EO14028: 4e(vi), 4e(vii), 4e(ix), 4e(x)

NTIASBOM: All

OWASPSCVS: 1.4, 2

SCSIC: Vendor

Software Delivery Integrity Controls

SCTPC: MAINTAIN3

SP80053: SA-8, SR-3,

SR-4

SP800161: SA-8, SR-

3, SR-4

Design Software to

Meet Security Requirements and Mitigate Security

Risks (PW.1):

Identify and evaluate the security requirements for the software; determine what security risks the software is likely to face during operation and how the software’s design and architecture should mitigate those risks;

and justify any cases where risk-based

PW.1.1: Use forms of risk modeling – such as threat modeling, attack modeling, or attack surface mapping – to help assess the security risk for the software.

Example 1: Train the development team (security champions, in particular) or collaborate with a risk modeling expert to create models and analyze how to use a risk-based approach to communicate the risks and determine how to address them, including implementing mitigations.

BSAFSS: SC.1

analysis indicates that security requirements should be relaxed or waived. Addressing security requirements and risks during software design (secure by design) is key for improving software security and also helps improve development efficiency.

Example 2:

Perform more rigorous assessments for high-risk areas, such as protecting sensitive data and safeguarding identification, authentication, and access control, including credential management.

BSIMM: AM1.2,

AM1.3, AM1.5,

AM2.1, AM2.2,

AM2.5, AM2.6,

AM2.7, SFD2.2,

AA1.1, AA1.2, AA1.3,

AA2.1

Example 3: Review vulnerability reports and statistics for previous software to inform the security risk assessment.

EO14028: 4e(ix)

Example 4: Use data classification methods to identify and characterize each type of data that the software will…