Open Source Security Foundation (OpenSSF) Scorecards provide a way for open source users to determine whether maintainers are being diligent about securing their link in the software security supply chain. Practices such as pinning dependencies, branch protection, required reviews, continuous integration tests etc. are measured to provide a score and accompanying badge. This presentation will provide a walkthrough of the steps involved in securing a first repository, and then what it takes to repeat that process across and organization with multiple repos. It will also look at the ongoing maintenance involved once scorecards have been implemented, and how aspects of that maintenance can be better automated to minimize toil.

1. Showing that you care about security
OpenSSF Scorecards - Chris Swan
https://stateofopencon.com/ #stateofopencon #soocon24 #openuk
https://hachyderm.io/@openuk

4. Hi, I’m Chris
@cpswan
https://chris.swanz.net

5. Agenda
• Who are OpenSSF, and what is a scorecard?
• Start with Allstar
• Doing your first repository
• Scaling across multiple repositories
• 80:20
• The toil of it all

6. (Visibly) well maintained
software is more
sustainable software…
requiring less time and
resources to keep up to
date and adapt to the
changing world around us.

7. Who are OpenSSF,
and what is a scorecard?

8. https://openssf.org/

10. Start with Allstar

11. https://github.com/ossf/allstar

12. A whole bunch of config,
and a whole bunch of files

13. Doing your first repository

14. Expect LOTS of issues

15. Help is at hand

16. Dependency (pinning) hell cont…

17. Scaling across multiple
repositories

18. Rinse and repeat - more of this

19. And more of this

20. 80:20

21. There will be a residue

22. This is where it gets really gnarly

23. The questionnaire is long and detailed

24. And some sections might be hard to accomplish

25. The toil of it all

26. Make friends with the new boss

27. From a docs repo
(no actual code to maintain)

28. From a code repo

29. Dockerfiles need rollups

30. rollup.sh
#!/bin/bash
if [ $# -ne 2 ] ; then
echo "Usage rollup.sh <BASE_PR> <LAST_PR>"
exit 1
fi
BASE_PR=$1
LAST_PR=$2
git pull
gh pr checkout "$BASE_PR"
for (( i=(($BASE_PR + 1)); i<=$LAST_PR; i++ ))
do
PR_BRANCH=$(gh pr view "$i" --json headRefName -q .headRefName)
git merge origin/"$PR_BRANCH" -m
"build(deps): Rollup merge branch for #${i} ${PR_BRANCH}"
done
git push

31. Scorecard’s own dependencies can
change with annoying regularity
(in every repo with a scorecard)

32. Base dependencies can be amplified

33. Review
• An OpenSSF Scorecard can show you care about security.
• Allstar provides a good starting point.
• Pick a first repo to get a hang of what’s needed.
• Then automate across the rest of the organisation.
• 20% of the effort to get 80% of the score.
• Scorecards do create ongoing toil that needs to be
minimised.

34. Call to action: Run the
scorecard CLI against
one of your own repos
https://github.com/ossf/scorecard#
scorecard-command-line-interface

35. Resources
Blog posts
https://blog.thestateofme.com/2022/12/02/implementing-os
sf-scorecards-across-a-github-organisation/
https://blog.thestateofme.com/2023/03/09/roll-up-rollup-ge
t-your-dependabot-prs-together-here/
atGitHub
https://github.com/atsign-foundation/.github/blob/trunk/docs
/atGitHub.md
Varun Sharma’s (Step Security) QCon Demo Org
https://github.com/qcon-demo-org

36. DEI: Having your repo
comply with community
guidelines with things like a
code of conduct is an
integral part of the
OpenSSF best practices that
form a part of implementing
scorecards.

37. Thanks for your time
Chris Swan @cpswan
chris@atsign.com

38. #stateofopencon #soocon24 #openuk