Re: [SCITT] CISA: Repository for Software Attestations and Artifacts (RSAA)

[Steve Lasker <[e-mail]>]

Good timing, Ray,
A.J. was going to facilitate the SCITT Community Meeting next week, and the Software Attestations was his first topic.
Reminder: Community meetings restart on April 8th 4 PM UTC (groups.io)<https://groups.io/g/scitt-community/message/73>

--> Does this actually do anything to improve software by having producers say they do everything right?

This is the interesting part, and why enabling others to comment on the same artifact is so important.
There are two major categories of vulnerabilities:

  1.  A software vendor/project inadvertently published a vulnerability. It may not have been known at the time, or it was a bug. In this case, the vendor/project is motivated to fix it. They're motivated to put testing in, to catch their mistakes. They're motivated to publish new information about their artifacts, indicating they found an issue and the steps they're taking to resolve it.
  2.  A group is maliciously working to circumvent the security gates. They study all known checks, and intentionally design a vulnerability to get through them undetected. The better funded, the more they can invest. In this case, they're not motivated to communicate problems.

In both cases, it's important for others to make statements about other publishers artifacts. Verifiers can choose which additional publishers they wish to trust. Otherwise, a malicious company can pretend to be a good security company and say good, or bad things about software.
This was captured here, on scitt.io: Extending Services - SCITT - Supply Chain Integrity and Trust<https://scitt.io/scenarios/extending-existing-services.html>

This brings up the value of the subject field, where multiple issuers can make additional statements about the same artifact.

At IETF 119, it was discussed the challenges with combining issuers and unique subjects, and I'd like to carve that problem out as a focus. So, that we can assure we can support the above scenarios.



From: SCITT <[e-mail]> On Behalf Of Ray Lutz
Sent: Friday, April 5, 2024 2:22 PM
To: [e-mail]
Subject: [SCITT] CISA: Repository for Software Attestations and Artifacts (RSAA)

This seems to implement a service similar to the vision of SCITT, but with the user account, and submission front end that is otherwise missing from SCITT, and it appears to be already endorsed by CISA. They use "self attestations" which are comparable to SCITT claims. It seems it is limited to federal users and sw vendors.

https://www.cisa.gov/resources-tools/resources/repository-software-attestations-and-artifacts-rsaa-user-guide

https://www.cisa.gov/sites/default/files/2024-03/CISA_RSAA_User_Guide_18_March_2024.pdf

and they use this self-attestation form:
https://www.cisa.gov/sites/default/files/2024-03/Self-Attestation-Common-Form-03082024-FINAL.pdf

--> Does this actually do anything to improve software by having producers say they do everything right?



Intro text:
==============
PURPOSE

OMB issued memorandum M-22-18 on 14 September 2022. Due to the importance and scope of the Federal Government's information and communications technology (ICT) products and services, Memorandum 22-18 was drafted to ensure software integrity. Software integrity is key to protecting Federal systems from nation state and criminal actors seeking to disrupt our nation's critical functions. The goal is to reduce overall risk from cyber-attacks. One way to achieve this is by Federal agencies only using software from software producers who can attest to complying with the Government-specified secure software development practices, as described in the NIST Guidance.

Following the issuance of M-22-18, on 09 June 2023, OMB issued memorandum M-23-16. OMB Memorandum M-23- 16 reinforces the requirements established in M-22-18, reaffirms the importance of secure software development practices, and extends the timelines for agencies to collect attestations from software producers. Additionally, this memorandum provides supplemental guidance on the scope of M-22-18's requirements and on agencies' use of Plan of Actions and Milestones (POA&Ms) when a software producer cannot provide the required attestation but plans to do so. To the extent any provision of this memorandum may be read to conflict with any provision of M-22-18, this memorandum is controlling.

The Repository for Software Attestation and Artifacts (RSAA) serves to satisfy the requirements set forth in M-22-18 and M-23-16.

INTRODUCTION

The RSAA User Guide provides users with instructions to create an RSAA account, the required CISA Okta Partner Platform account with multifactor authentication (MFA) and use the RSAA application effectively. The RSAA application serves as a repository for all software producers' Attestations.

==============
Steps are:
1. Create a user account. It lists some but also has a way to request additional categories.
"If the organization or agency being represented does not appear in the drop-down lists or options presented,
please contact the CISA Technology Operations Center (TOC) to request the missing organization or agency be added to
the CISA RSAA system"

[cid:image001.png@01DA876E.64EC48D0]
Click "Submit for Review." A notification will appear confirming the account creation request has been successfully submitted. Click "OK" to complete the process. Account requests are reviewed and processed within approximately 2 business days. Upon processing, an email is sent to the requestor to notify that the account has been created.

2. Create a software record.
With an RSAA account created AND activation of the CISA Okta Partner Portal account with MFA, registered users may
create software record(s) for the agency or organization. Each record is specific to the software product and version(s).
Registered users may also search existing software records, subject to the user privileges.

Step 6. If creating a new software record, complete the required fields in the Create Software Record form which displays and identifies required data for the submission:
a. Populate the Name of Product or Product Line field.
b. Enter the Version Number Range (if applicable).
c. Enter the software producer entity. If the software producer is not registered in the system, Click the "Add New" option, and when prompted, enter the software producer entity, and click "OK." The entity will now be available to enter in the software producer field of the Create Software Record form.
d. Enter the Release/Publish Date.
e. Click "Save Record."

artifacts may be uploaded using the "Upload Artifact" feature.




--

-------

Ray Lutz

Citizens' Oversight Projects (COPs)

http://www.citizensoversight.org<http://www.citizensoversight.org/>

619-820-5321