Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 19 submissions in the queue.
Politics
posted by janrinok on Wednesday September 28 2022, @05:10PM   Printer-friendly
from the homespun-security dept.

US Senators Gary Peters (D-MI) and Rob Portman (R-OH) introdced S.4913 - Securing Open Source Software Act of 2022 the other day. It has been read twice and referred to the Committee on Homeland Security and Governmental Affairs. Here is the US Senate's press release:

U.S. Senators Gary Peters (D-MI) and Rob Portman (R-OH), Chairman and Ranking Member of the Homeland Security and Governmental Affairs Committee, introduced bipartisan legislation to help protect federal and critical infrastructure systems by strengthening the security of open source software. The legislation comes after a hearing convened by Peters and Portman on the Log4j incident earlier this year, and would direct the Cybersecurity and Infrastructure Security Agency (CISA) to help ensure that open source software is used safely and securely by the federal government, critical infrastructure, and others. A vulnerability discovered in Log4j – which is widely used open source code – affected millions of computers worldwide, including critical infrastructure and federal systems. This led top cybersecurity experts to call it one of the most severe and widespread cybersecurity vulnerabilities ever seen.

[...] The overwhelming majority of computers in the world rely on open source code – freely available code that anyone can contribute to, develop, and use to create websites, applications, and more. It is maintained by a community of individuals and organizations. The federal government, one of the largest users of open source software in the world, must be able to manage its own risk and also help support the security of open source software in the private sector and the rest of the public sector.

The Securing Open Source Software Act would direct CISA to develop a risk framework to evaluate how open source code is used by the federal government. CISA would also evaluate how the same framework could be voluntarily used by critical infrastructure owners and operators. This will identify ways to mitigate risks in systems that use open source software. The legislation also requires CISA to hire professionals with experience developing open source software to ensure that government and the community work hand-in-hand and are prepared to address incidents like the Log4j vulnerability. Additionally, the legislation requires the Office of Management and Budget (OMB) to issue guidance to federal agencies on the secure usage of open source software and establishes a software security subcommittee on the CISA Cybersecurity Advisory Committee.

-- Peters and Portman Introduce Bipartisan Legislation to Help Secure Open Source Software

Software freedom is not named explicitly in their definition as far as their diff^wtext goes. Nor are the free-of-charge, royalty-free aspects mentioned. Yet the text of S.4913 nevertheless seems to be a nod in the direction of Free Software:

(5) OPEN SOURCE SOFTWARE.—The term 'open source software' means software for which the human-readable source code is made available to the public for use, study, re-use, modification, enhancement, and re-distribution.

Behind the scenes, representatives from Microsoft appear to be milking the log4j circus for gain as shown by multiple other articles, not linked to here, and their vastly increased activity and presence in DC.

Overall, the legislative process needs to find a way to use versioning software so that all the "inserting before ...", "inserting after ...", "redesignating paragraphs ...", and other modifications can be easily processed and the current draft easily visible. However, that's not as simple as opening an account on GitLab or Src.ht and letting m$ and the rest of the world hammer at it unauthenticated and uncurated.

Previously:
(2022) The US Military Wants To Understand The Most Important Software On Earth
(2021) 'The Internet's on Fire': Techs Race to Fix Major Cybersecurity Software Flaw


Original Submission

 
This discussion was created by janrinok (52) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by ElizabethGreene on Wednesday September 28 2022, @05:29PM (5 children)

    by ElizabethGreene (6748) Subscriber Badge on Wednesday September 28 2022, @05:29PM (#1274062) Journal

    Bias disclosure: I work for Microsoft, therefore my opinion is invalid.

    I'd like to see the framework requirements in Sec 2220E.c.2.A (https://www.congress.gov/bill/117th-congress/senate-bill/4913/text#id2E6B3340D2094A61B77A7380FFAB5D39) expanded to include both Open and Closed Source software. It's not unreasonable to ask all federal software vendors to include an OSS BOM and simultaneously answer those questions vis-a-vis their software.

    The requirements from that section are...

    “(A) FRAMEWORK.—Not later than 1 year after the date of enactment of this section, the Director shall publicly publish a framework, incorporating government, including those published by the National Institute of Standards and Technology, industry, and open source software community frameworks and best practices, for assessing the risk of open source software components, including direct and indirect open source software dependencies, which shall incorporate, at a minimum—

    “(i) the security properties of code in a given open source software component, such as whether the code is written in a memory-safe programming language;

    “(ii) the security practices of development, build, and release processes of a given open source software component, such as the use of multi-factor authentication by maintainers and cryptographic signing of releases;

    “(iii) the number and severity of publicly known, unpatched vulnerabilities in a given open source software component;

    “(iv) the breadth of deployment of a given open source software component;

    “(v) the level of risk associated with where a given open source software component is integrated or deployed, such as whether the component operates on a network boundary or in a privileged location; and

    “(vi) the health of the community for a given open source software component, including, where applicable, the level of current and historical investment and maintenance in the open source software component, such as the number and activity of individual maintainers.

    Realistically though, knowing what a clown-show the federal procurement process is, $Vendors are unlikely to let that happen.

    Starting Score:    1  point
    Moderation   +1  
       Interesting=2, Overrated=1, Total=3
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by Thexalon on Wednesday September 28 2022, @07:37PM (1 child)

    by Thexalon (636) on Wednesday September 28 2022, @07:37PM (#1274084)

    So the thing about that is that doing that with closed-source software is basically impossible:
    1. You can't simply rely on what the vendor tells you, because all vendors regardless of their condition will swear on their mother's grave that their software is perfectly secure, extremely popular, with minimal risk, and has a healthy community of support staff and users. That largely renders points (i), (ii), (iv), (v), and (vi) in your list moot.
    2. You can't really rely on the vendor sharing source code with the government to verify point (i), because the code that gets compiled / interpreted and released might not match the code shared with the government.
    3. Even if you have a scrupulously honest vendor, the often-closed-source compiler / interpreter might be intentionally introducing vulnerabilities.
    4. The number and severity of publicly-known, unpatched vulnerabilities, point (iii), really isn't a great metric when comparing open-source and closed-source software, because closed-source software is more likely to have not-publicly-known but unpatched vulnerabilities, simply because there are fewer good-guy eyes looking at the code for problems.

    Doing this really right would involve having the government, probably under the NSA or somebody like that, with a team of programmers going through any open-source package used by the US government and contributing security fixes, which would also help all the private users of that package. So far, they've been reluctant to do that, largely because while they want the US government secure they also want foreign governments insecure so they can get a signal-intelligence advantage. So what we're probably going to see come out of this is a US-government version of the less secure software that gets deployed onto their machines but is not distributed.

    --
    Vote for Pedro
    • (Score: 2, Interesting) by Sjolfr on Wednesday September 28 2022, @09:48PM

      by Sjolfr (17977) on Wednesday September 28 2022, @09:48PM (#1274105)

      3.5 - there is no way to see the competency of closed source developers so any guidelines become useless pretty quick.

      Most opensource projects would eventually reject government packages because they would be introducing specific things that may break the vision of the developers anyway. That's the beauty of opensource ... government can hire vetted developers and make changes to the code and produce government only packages.

      And, much like the UofMN failed attempts that got them banned from linux kernel contributions, they (gov or individuals) can easily see and track all the code and remove the crap some idiot/terrorist tries to add.

      Opensource is a government dream as long as they can keep competent developers on staff.

  • (Score: 2) by legont on Thursday September 29 2022, @11:51PM (2 children)

    by legont (4179) on Thursday September 29 2022, @11:51PM (#1274259)

    such as whether the code is written in a memory-safe programming language

    C, C++ and Assembly do not qualify.

    --
    "Wealth is the relentless enemy of understanding" - John Kenneth Galbraith.
    • (Score: 2) by ElizabethGreene on Friday September 30 2022, @02:56AM (1 child)

      by ElizabethGreene (6748) Subscriber Badge on Friday September 30 2022, @02:56AM (#1274286) Journal

      No language is memory safe if you use it wrong enough. :)

      • (Score: 2) by legont on Friday September 30 2022, @08:48PM

        by legont (4179) on Friday September 30 2022, @08:48PM (#1274374)

        You are probably right, but my point was the legal angle. Are we about to outlaw C? It is a very serious question.

        --
        "Wealth is the relentless enemy of understanding" - John Kenneth Galbraith.