►
From YouTube: Scorecards Biweekly Sync (January 27, 2022)
Description
Notes and agenda: https://docs.google.com/document/d/1dB2U7_qZpNW96vtuoG7ShmgKXzIg6R5XT5Tc-0yz6kE/edit#
B
C
D
Hello,
this
is
eric
tyson
with
wipro
technologies.
I
lead
the
technical,
consulting
and
center
of
excellence
for
the
open
source
program
office
within
wipro
and
we're
doing
a
lot
of
initiatives
around
software
supply
chain
security
this
year
and
working
to
become
more
involved
in
open
ssf
in
general
on
a
number
of
working
groups.
D
E
E
F
So
I
believe
I
might
be
the
only
other
new
person
here,
although
I'm
not
new
to
a
couple
of
you
hi,
I
am
vm
brassur.
You
can
call
me
vicky
because
we're
all
friends
here
I
work
with
eric
at
wipro
we're
both
in
the
open
source
program
office.
I
am
a
director
and
senior
strategy
advisor
here
at
wipro
and
the
open
source
program
office.
I've
been
around
for
an
open
source
software
for
a
long
time
been
in
a
lot
of
different
spaces.
F
I
work
with
mr
augustus
the
to
do
group
and
the
steering
committee.
I
know
mr
wheeler
from
spdx
and
various
other
things
yeah,
so
I've
just
been
around
and
the
software
supply
chain
is
something
I've
been
concerned
with
and
working
on
for
several
years.
So
I'm
very
excited
to
see
the
direction
that
that
this
project
has
been
taking
and
decided
time
to
start
chipping
in.
B
G
G
H
Hey,
I
guess,
we're
doing
interest.
My
connection
went
for
a
minute,
so
hi,
I'm
bella
weisman,
I'm
leading
engineering
for
open
space
at
goldman
sachs.
We
recently
joined
the
open,
ssf
and
definitely
looking
at
how
we
can
leverage
things,
including
the
scorecards,
to
help
with
our
open
source,
consumption
and
contribution.
So
the
scorecard
looks
really
interesting
and
looking
forward
to
learning
more
about
it,
especially
programmatic
integration,
most
important
cool.
I
J
B
Me
cool:
I
can
go
next,
so
amazing
I
I
primarily
work
on
scorecards
yeah.
I
also
sometimes
help
help
out
jeff
with
ultra,
so
just
in
case
volkswagen
no
all-star
is.
Is
this
other
project
that
works
integrates
very
well
with
scorecard?
It's
a
policy
part
that
also
this
group
is
trying
to
develop.
So,
if
you're
interested
in
scorecard,
I
would
highly
recommend
you
check
out
all-star
too.
K
Okay
sure
so
my
name
is
jonathan
metzman.
I
work
at
google
on
oss
fuzz,
which
is
a
fuzzing
solution.
That's
used
by
a
lot
of
open
source
projects
that
probably
many
people
use
like
open,
ssl
and
curl,
and
I'm
basically
wanted
to
discuss
some.
You
know
how
how
sort
of
scorecards
is
gonna.
You
know
how
it
like
integra,
how
you
know
how
it
basically
integrates
with
the
fauceting.
L
M
B
K
K
That's
a
bit
unusual,
which
is
that,
in
order
to
build
the
actual
project,
you
know
the
actual
projects.
Fuzzers,
you
need
the
sort.
You
need
the
up-to-date
source
code
of
the
action.
You
know,
there's
actually
almost
like
a
dependency
on
the
action
from
the
source
repo.
You
know
for
the
for
the
repo
that's
using
the
action,
and
so
you
know
this
makes
it
really
hard
to
pin
ci
fuzz
as
an
action,
because
you
know
suppose
a
user
of
ci
fuzz
were
to
update
their
docker
file.
L
I
would
suggest
that,
where
possible,
instead
of
an
exception,
that
we
tweak
the
criteria
to
what
was
meant,
if
that's
appropriate,
so
that
you
know
the
next
group,
if
they're
in
a
similar
situation,
doesn't
have
to
make
the
request.
The
trick,
of
course,
is
to
figure
out.
If
we
can
craft
it,
what
that
language
would
look
like,
I'm
not
opposed
per
se
to
an
exception,
but
if,
if
the
requirement's
too
broad,
maybe
we
need
to
refine
it,
and
I
see
jonathan
raised
his
hand,
which
I
probably
should
have
sorry
about
that.
N
It
sounds
like
the
pro,
so,
if
my
understanding
is
the
salsa,
the
salsa
or
the
the
high
level
problem
is
that
you
want
the
build
that
is
being
used
to
build
the
artifact.
That
is
the
release
from
the
build
to
be
the
thing
that
is
immutable
right,
so,
presumably
an
auxiliary
build
that
runs
in
parallel.
As
long
as
that,
build
is
being
run
in
such
a
way
that
it
is
not.
The
thing
that
is
producing
the
published
artifacts
could
theoretically
be
the
thing
that
is
unpinned
and
as
long
as
you're,
not
using
oss
fuzz.
N
As
a
part
of
your,
like,
you
know
the
output
of
whatever
the
thing
is,
that
is
using
oss
fuzz
as
part
of
your
result
in
build
artifacts.
That
would
be
something
that
would
be
potentially
safe
right,
like
not
pinning
for
things
that
are
part
of
resultant,
build
artifacts
that
are
going
to
be
relied
upon
by
downstream
users.
L
N
But
I
presume
that
the
what
the
goal
here
is
is
to
make
sure
that,
if
things
are
unpinned
that
they
are
running
in
an
environment
that
is
intentionally
segregated
off
from
the
rest
of
the
infrastructure,
such
that,
if
that
thing
is
unpinned,
it
can't
maliciously
impact
the
build
results
of
the
other.
The
other
ci
pipelines.
N
Send
to
the
production
yeah
right
exactly
so
is
it
is
the
concern
about
pinning
that
you
don't
want
something
to
be.
You
know
somebody
to
hijack
an
account
and
then
be
able
to
publish
a
new
version
of
that
thing
for
for
typo
spotting
or
something
similar,
or
what
is
the
high
level
goal
of
trying
to
prevent
you
know
or
requiring,
requiring
a
locked
in
commit
version,
or
something
like
that?
Okay,.
J
Can
I
unpack
that
specifically
on
why
you
will
need
that
to
be
pinned?
Okay,
the
example.
The
simple
attire
factor
is,
and
you
can
have
an
action,
get
up
action
that
is
not
pinned
and
you
might
be
using
on
a
specific
git
tag
and
it
could
not
it
and
everything
is
fine
and
dandy,
and
one
fine
day
somebody
malicious,
even
the
gab
or
somebody
else.
Can
you
can
start
siphoning
your
secrets
from
yourself
from
github
into
their
own
custom
server,
but
you'd
be
trusting
that
the
shah
never
changed
by
using
the
version.
N
J
E
M
Yeah,
something
I
wanted
to
add
is
that
you
know
having
hash
pinning
is
essentially
very
similar
to
having
code
review.
So,
basically
you,
what
you
run
is
what
you've
reviewed.
So
if
you
have
cleaning
it
tells
you
exactly
the
exact
copy
of
the
dependency
that
you're
running
and
if
you,
if
you
ever
get
an
incidence
response
when
you
need
to
check
okay,
when
was
I
vulnerable,
then
you
can
go
back
to
your
commit
history
and
you
can
look.
M
You
can
look
at
those
hashes
that
were
vulnerable,
which
is
going
to
be
a
lot
smaller
than
this
wide
range
version,
one
that
probably
is
like
you
know.
You've
been
running
version,
one
for
a
very
long
time,
so
that's
gonna
make
it
a
lot
more
difficult
for
you
to
pinpoint
you
know
the
specific
runs
of
your
workflows
that
were
vulnerable
or
not.
K
Yeah,
I
mean
one
thing
I'll
add
there,
I
think,
is
that
github
actions
actually
sort
of
like
logs.
I
think
that
commit
that
the
action
was
run
on.
I
believe,
but
I
you
know
that
I
think
the
log
like
possibly
you
know,
might
not
be
retained
forever
and
obviously
you
know
it
would
be
easier
if
you
just
like,
could
see
okay,
it
stopped
here,
but
actually
I
had
a
question
actually
about
what
naveen
said
just
because
I
think
it
raised
an
interesting
point,
which
was
that,
like
yeah
like
what?
K
What
is
the
what
is
like
the
harm
of
a
sort
of
like
rogue
github
action,
and
it
would
would
it
be
possible
to
you
know
in
the
workflow,
basically
like
lock
it
down,
so
that
you
know
the
worst
thing.
You
know
a
malicious
ci
fuzz
action
could
do
is
just
tell
you
that
you
have
like
a
fuzzing
bug
when
you
don't
actually
like
what
like
is
that
possible,
or
is
this
not
possible
with
github
actions.
A
E
C
I
can
say
is
that
you
know:
let's
say
someone
was
running
a
workflow
where
they're
running
os,
fuzz
and
they're.
Not
actually
you
know
doing
anything
else,
so
you
could
actually
then
restrict
the
github
token
permission
for
that
workflow.
You
know,
and
you
can
say
that
this
is
contents
read,
and
I
mean
I'm
assuming
oss
first
doesn't
need
anything
else.
So,
even
if
oss
fuzz
were
to
get
compromised,
you
know
one
can
then
not
steal.
Let's
say
the
github
token.
C
The
problem
is
that
you
cannot
really
tell
all
the
developers
to
not
use
oss
fuzz
in
workflows.
You
know
that
also
have
their
docker
secrets
and
stuff
like
that.
So
what
happens
is
they
can
have
this
one
big
workflow,
which
is
doing
their
test
and
build
and
release
publish
to
you
know,
nougat
and
and
npm,
and
all
that
places
and
then
that
you
know
governance
gets
very
hard
to
do
in
fact
token
permissions
getting
getting
them
to
set
open.
C
N
Yeah,
because
couldn't
you
couldn't
you
check
your
permissions
right,
like
you
know,
I
I,
for
example,
was
doing
ssh
keys
on
my
local
machine,
and
you
know
openssh
can
pitch
to
fit
when
I
had
wrong
permissions
on
the
file
like
it
had
all
open
permissions
when
it
tried
to
open
the
file
right.
Couldn't
you
just
do
something
similar
with
os
os
fuzz,
where
it
pitches
a
fit?
E
Yeah,
so
something
that
was
mentioned
in,
I
think
as
we're
talking
about
like
the
the
scorecard
pre-submits
themselves
right
is
that,
like
we
have
an
opportunity
to
kind
of
like
split
out
the
scorecard
pre-submits
into
like?
Are
we
building
or
are
we
testing?
Are
we
verifying
something
right?
The
verify
scripts
shouldn't
need
any
permissions
to
run
right.
This
is
something
that
you
can
segment
to
a
separate
github
action
that
has
only
read
to
the
repo
supposedly.
L
I
think
are
we
tracking
this
yeah?
I
think
what
we
should
do
is
is
figure
out
what
the
right
criterion
is
hopefully,
and
then
figure,
and
you
know
working
out
how
to
automate
it
and
not
be
necessarily
constrained
to
what
the
tool
currently
can
find
today,
as
long
as
we
can
figure
out
a
way
to
get
there
so.
B
Yeah,
sorry,
I
I
mean
I
was
just
acting
on
to
what
lauren
said
like
I
wonder
if
the
criterion
here
should
be,
we
only
penalize
unpinned
github
actions.
If
that
particular
action
has
potential
of
leaking
secrets,
so
we
kind
of
actually
do
that
in
two
different
ways.
Now
we
we
do
it
using
dangerous
workflows
and
dependencies
separately.
I
wonder
if
scorecard
should
be
like
you
know,
we
be
a
little
more
smart
about
it
and
that
way
we
don't
need
a
special
exception
for
oss.
For
this.
L
L
I
would
say
it's
all
cia,
you
know
if,
if
the
subverted
one
can
cause
either
release
of
data
supposed
to
be
kept
secret
or
it
can
subvert
the
later
pipeline,
then
I
think
we
start
worrying
if
it's
just
a
whether
or
not
it
passes.
I
guess
that's
an
availability
concern,
but
I
I
think
we
can
accept
that
the
hey
it
you
know,
I
didn't,
pin
it
and
it
produced
a
fail
when
it
should
have
produced
a
success.
L
L
M
Yeah
that
would
that
would
already
go
a
long
way.
I
think
what
azim
said
about
token
permissions
and
dangerous
workflows
being
two
different
checks
today
and
we've
already
thought
of
kind
of
merging
those.
Two
at
some
point,
then
we,
I
guess,
we'll
reduce
the
number
of
people
who
complain.
I
suppose
there'll
still
be
people
who
say
hey,
I
have
a
workflow
and
guess
what
it's
it's
calling
into
gcp.
So
now
I
have
access
to
gcp
stuff.
M
B
So
if
I
understand
correctly,
I
mean
I
I'm
trying
to
summarize
it.
I
could
be
wrong,
but
I
think
that
two
directions
are
like
two
solutions
here.
One
is:
is
we
can
solve
it
on
on
the
policy
side
of
it?
Basically,
we
can
still
complain
and
say
that
hey,
you
have
a
ci
first
action
which
is
unpinned,
but
you
can
ignore
it
using
policy
and
the
other
is.
K
So
I
mean,
I
frankly
think
both
are
good.
Ideas
like
improving
scorecards
to
be
more
accurate,
is
great
and
I
think,
having
the
ability
to
turn
things
off.
You
know
like
sorry,
my
policy
meant
it's
like
per
repo
specific,
like
they
could
say
like.
Actually,
this
is
okay
yeah.
I
mean,
I
think,
that's
a
terrific
idea
and
I
think
I
I
won't
even
go
into
just
cause.
K
It's
not
the
point
of
why
I
came
today
like
we
do
want
to
use
scorecards
on
oss
fuzz
and
oss
fuzz
like
within
the
repo
like
has
like
you,
know,
tons
and
tons
of
unpinned,
docker
images
and
that's
you
know,
and
that's
sort
of
by
design,
and
you
know
many
other
unpinned
things
and
pulling
from
master.
You
know,
because
we
need
to
build
the
latest
thing
and
you
know
having
just
having
the
ability
for
like
the
repo
owner
to
you
know
actually
like
clarify
like
no,
this
is
really
okay.
M
So
because,
if
we
let
you
just
decide,
what's
good
and
not
good,
like
you
know,
that's
kind
of
an
open
door
for
everyone
to
say.
Oh,
this
is
fine,
just
ignore
it.
So
if
we
want
to
go
that
way
of
saying
this
is
okay
for
my
repo,
I
guess
there
has
to
be
some
sort
of
vetting
process
where
it's
pretty
it's
clear
that
okay
ossf
has
agreed
that.
M
L
Updating
that
no,
as
in
the
project,
can
put
in
their
repo
some
file
that
says
hey,
I
know
scorecard's
going
to
say
this
doesn't
work.
We
say
it's
okay
and
here's.
Why
and
then
you
can
get
a
report
that
says
like
here's,
the
scorecard
data
and
here's
what
the
project
asserts
the
value
is
and
why
they
believe
that
so.
L
H
H
L
Then
I
would
suggest
don't
bother
with
an
ignore
file.
Just
have
it
done.
Do
it
automatically.
Now
I
will
say
from
experience
with
the
best
practices
badge.
The
number
of
things
that
you
can't
automate
is
is
discouragingly
large.
That's
why
we
have
some
automation,
but
most
of
the
criteria
are
not
automated
because
we
went
exactly
the
opposite
direction
of
scorecard.
What's
important,
not
what
can
be
automated
the
skirt
card.
Folks,
are
this
group?
How
what
can
we
automate?
It's
a
good
question
and
each
approach
has
its
pros
and
it's
cons.
L
M
M
H
M
Yeah
absolutely,
but
I
think
those
are
two
different
use
cases.
There's
someone
looking
at
a
repo
that
just
wants
to
see.
Okay,
is
it
good,
not
good
and
there's
someone
who
tries
to
automate
everything
that
flows
into
their
their
prod
and
there
you
can
there
you'll
be
able
to
actually
use
policies
to
write
what
you
you
want,
what
you
don't
want
and
that
will
be
independent
and
whatever
the
score
of
scorecard
is
because
we're
building
this
new
feature
in
scorecard.
M
Where
we'll
give
you
the
raw
results,
and
you
can
decide
that
the
action
name
was
ossf,
that's
fine
with
me
and
you
can
decide
that
this
is
fine
and
you
don't
have
to
look
at
the
score
or
like.
So
I
think
I
think
the
scores
are
more
more
for
human,
but
for
for
machines,
like
the
policies
will
be
there.
E
So
I
just
wanted
to
know
yeah
yeah,
so
just
want
to
note
here
that,
like
some
of
what
we're
talking
about
like
this
being
able
to
opt
in
and
opt
out
like
that,
not
specifically
for
this,
but
that
configuration
ability
capability
exists
in
all-star
already
right.
If
you
plop
all
star
on
and
you
configure
your
org
you've
got
a
bunch
of
config
files
to
flip
these
dials
is
it
you
know,
would
it
be
useful?
Is
it
possible
that
we
extract
some
of
that
logic
and
bring
it
into
a
place?
B
So
there
are
two
problems
here
right:
one
is
the
consumer
producer
type
of
a
thing
one
is
our
repositories
want
to
improve
their
own
scorecard
scores,
or
rather
they
they
want
to
make
sure
that
they
don't
get
false
positives,
for
which
there
is
the
policy
file
solution
that
laurent
is
working
on
currently,
but
there's
also.
The
other
side
like
bella
said
where
they
want
to
probably
use
an
api
and
get
their
dependencies
scorecard
and
that
shouldn't
be
opinionated
and
that's
also
what
we
want
there.
L
B
B
H
Yeah,
I
was
going
say
that
like,
but
the
more
information,
the
better
meaning,
like
I
don't
know
as
a
as
a
program
right
but
something's
unpinned,
whether
that's
safe
or
not.
I
need
more
information
to
make
that
determinate
determination.
Maybe
it
can
be
done
programmatically,
maybe
not,
but
like
just
like,
I
can't
craft
a
policy
without
data
on
whether
it
is
or
is
not
safe.
So
that's
like
both
are
required.
I
think.
L
L
L
And
you
know-
and
it
may
turn
out,
for
example,
that
here's
the
reason.
Oh,
that
reason
is
ridiculous
that
doesn't
apply.
Well,
then,
there's
no
reason
that
you
need
to
do
that,
and
so
that
would
you
know
unfortunately
bella.
That
would
mean
that
you
have.
You
might
have
to
go
back
and
see.
Let's
see
that
for
now,
because,
but
at
least
you'd
have
some
information
to
work
with.
M
M
Useful
to
be
sure
when
in
in
the
right
direction
and
what
we
can
do
in
the
next
meetings,
we
can
actually
show
you
maybe
the
structure
of
what
we
have
in
mind.
So
we
can
tweak
it
all
together
to
make
sure
that
this
seems
to
work,
because
I
think
azim
and
I
have
been
discussing
this
a
lot
and
are
we
still
not
sure
about
all
the
details
and
just
just.
I
The
idea
of
having
the
raw
data
and
then
writing
a
policy
also,
currently
I
mean
sorry
scorecards
currently
does
that,
like
it
gathers
data
and
it
has
a
built-in
decision
on
a
score,
which
is
what
is
publicized,
that
that
current,
like
default
policy,
will
be
available
right,
so
scorecards
will
still
have
like
a
default
scoring
and
a
policy.
That's
I
guess
the
the
recommended
one.
So
no,
you
know
nobody
has
to
start
from
scratch
and
decide
figure
out.
Do
I
like
pin
dependencies
or
not.
E
So
two
things
I
want
to
be
a
little
conscious
of
time
and
because
it
looks
like
we
have
a
few
other
things
on
the
agenda
and
two
like
is
this
documented,
like
the
work
that
you're
doing
in
terms
of
like
refactoring?
Some
of
this,
the
actual
request
is
any
of
it
documented
in
the
repo,
if
not
like,
we
should
link
that
stuff
up.
B
M
The
dog
doesn't
really
say
anything
about
the
the
structure
of
the
results,
which,
I
think
is
the
main
pain
point.
So
I
think
we
should
take
like
could
review
as
an
example
and
maybe
token
permission
dangerous
workflows,
because
those
basically
require
a
like
a
view
of
a
workflow.
So
I
guess
those
would
be
the
two
that
I
would
we
could
start
for
a
discussion
and
maybe
next
next
meeting
we
can,
I
mean
we
will
we'll
add
this
in
the
issue
and
next
meeting
we
can
bring
it
up
as
an
open
issue.
M
H
K
Like
the
you
know,
the
repo
itself-
and
you
know
I
I
guess
like
one
last
point
I
wanted
to
make-
is
like
I
sort
of
wonder
if,
like
you
know
just
like,
if
you
just
raise
the
fact
that
there's
this
like
pinning
issue
like,
is
that
making
you
know?
Should
consumers
feel
like
that,
like
the
repo
is
less
secure?
Because
of
that
or
you
know,
is
it
really
like
more
secure
in
the
end,
because
you
know
it's
fuzzing
and
then
another
point
I
would
think
might
be
interesting
to
think
about.
K
Is
that
at
least
like
you
know,
other
sorts
of
like
static
analysis
tools,
there's
almost
always
like
a
way
for,
like
you
know,
to
basically
flag
something
as
like
a
sort
of
false
positive,
and
you
know
I
suppose
that
could
be
just
because
the
consumer
is
different.
In
that
case,
like
it's,
you
know
like
someone,
you
know
like
you,
you
trust
yourself
that
you're,
you
know
labeling
it
properly,
but
you
know
it's
another
thing.
I
think
they
consider.
J
You
bought
it,
you
got
a
good
point.
Fuzzing
is
weaker
to
go
than
just
this,
but
it's
a
hard
problem
in
my
two
cents
on
this
giving
an
exception
like
having
an
exception
for
same
thing,
what
lauren
mentioned
giving
an
exception
to
one?
Then
it's
going
to
unpack
the
kind
of
worms
as
to
how
many
more
are
we
going
to
keep
doing?
What
are
the
criteria
and
all
that.
K
B
J
H
I
have
a
very
boring
process
related
thing,
just
as
the
maybe
the
only
person
here
from
like
a
bank,
I
am
not
allowed
to
use
chat
on
zoom.
Google
docs
is
also
blocked.
For
me.
I
don't
really
have
such
great
solutions,
but
just
kind
of
like
bringing
that
up.
So
just
I
don't
know
like
at
some
points
I
mean
maybe
I'll
take
it
offline
and
we
can
just
try
to
think
just
something
to
be
conscious
of.
H
H
E
So
we've
run
into
this
kind
of,
and
to
do,
group
two
and
vm
is
familiar
that
so
we
have
like.
Basically,
all
these
different
ways
to
chat.
Some
of
it
is
zoom
chat.
Some
of
it
is
slack.
Some
of
it
is
private
mailing
lists,
and
most
recently
we
created
like
a
private
discussion
forum
on
github.
For
folks
who
cannot
use
one
of
those
various
things
are,
would
people
be
in
favor
of
having
a
like
enabling
discussions
for
various
repos
here?
E
H
Thank
you
and
yeah.
Whatever
you're
doing
for
to
do
group
I
mean
that's
been
useful
right
like
you
can.
Google
groups
are
okay,
because
you
can
do
that
via
email,
which
is
fine
and
then
having
github
discussions.
I've
also
used
that.
So
those
are.
Those
are
all
good,
good
things,
and
I
mean
it's
fine,
like
you
guys,
can
definitely
chat
on
zoom,
but
like
just
being
conscious
that
some
of
us
can't
so
like.
I
can't
even
ask
you
like
on
zoom
on
the
chat.
Like
can
you
add
me
right
right,
yeah,
inclusive
inclusivity,.
C
You
know
I
use
in
terms
of
what
to
discuss
I
wanted
to
like.
I
don't
really
know
how
you
might
manage
the
agenda
and
stuff,
so
I
didn't
really
put
it
there,
but
I
wanted
to
have
a
discussion.
You
know
more
of
a
brainstorming
around
increasing
scorecard
adoption,
and
you
know
I
can
tell
you
what
my
interest
is
there
in
it.
C
I
mean,
of
course,
it's
good
for
everybody,
but
step
security
has
certain
solutions
which
help
you
you
know,
implement
the
scorecard
checks,
sort
of
automatic
remediation
things
like
setting
token
permissions
or
pinning
dependencies,
and
obviously
they
get.
You
know
used
more
by
the
open
source
community
if
there's
more
adoption,
so
so
I
just
want
to
sort
of
you
know,
have
a
discussion
about
what
are
the
ideas
or
what?
What
are
the
things
already
in
you
know
in
play
in
order
to
increase
the
adoption
of
scorecards.
B
I
I
can
speak
to
it
a
bit,
so
I
I
mean
we
are
basically
we
are
trying
to.
You
know
leverage
on
the
fact
that
we
are
a
part
of
openssf,
so
we
are
mostly
going
around
in
different
opennesses
of
working
groups
and
asking
folks
if,
if
you
are
part
of
the
open
ssf,
you
know
like
if
your
organization
is
part
of
openness
like
let's
say
it's,
microsoft
or
github-
we're
asking
folks
to
go
and
install
scorecard
on
your
repos.
So
so
far.
B
Actually
lawrence
scorecard
action
has
got
a
bit
of
traction.
So
we've
seen
some
of
tensorflow
and
flutter
from
google
have
already
installed
it.
So
you
know
we
are
hoping
that
we
can
get
some
of
these
big
commonly
used
critical
repos
to
kind
of
adopt
it
and
show
that
this
is
something
that
is
trustworthy.
B
I
B
Yeah,
we
do
have
the
website
coming
up
soon,
that
that
should
be
something
that's
kind
of
what
we're
planning
for
timeline
is
by
the
end
of
the
quarter
so
yeah.
That
is
another
hope
that
we
can
actually
increase
our
web
presence
so
that,
when
people
search
for
scorecard
today,
I
think
it
directs
them
to
something
else,
but
at
least
with
the
website.
We
can
include
that.
M
There
there
are
some
other
directions,
we've
talked
about.
Just
to
add
add
to
what
has
him
said.
So
I
think
one
is
through
the
omega
project,
so
we're
gonna
give
them
a
list
of
top
top
things
that
you
know
people
the
repo
maintainers
should
fix
once
they
finish
working
with
the
omega
alpha
omega
project
and
one
of
them
will
be
to
install
scorecard.
M
You
know
to
keep
track
of
issues.
We
also
have
the
the
work
stream
on
documentation
where
we
can.
You
know,
ask
users
to
install
scorecard
as
part
of
the
best
security
practices,
and
I
think
another
avenue
is
also
through
the
ci
badges
that
david
runs.
That
would
also
be
potentially
another
another
avenue.
I
know
we've
mentioned
it
before,
and
maybe
this
in
the
future.
So
another
thing
before
david,
maybe
replies
to
the
about
the
ci
badges
is:
do
you
think
we
should
try
to?
M
You
know
some
of
us
or
go
through
a
vendor
to
identify
some
of
the
critical
projects
and
try
to
work
with
them?
Maybe
by
send
you
know,
sending
a
pull
request
and
see
if
some
some
of
them
will
be
interested
in.
You
know
in
installing
scorecard:
is
that
a
good
approach
or
is
it
too
ad
hoc
or
like
any
thoughts?
I.
J
I
try
to
take
the
top
criticality
that
part
of
the
open
ssf,
which
figures
that
I
try
to
send
for
the
top
10
repost
guess
what
happened.
Most
of
them
didn't
didn't
care
about
it.
They
said
you
guys
it's
not.
We
are
not
going
to
take
this
a
headache,
we're
not
going
to
take
care
of
all
of
this,
so
it
is
hard
to
convince
because
security
is
not
a
primary
concern
right
now
for
at
least
the
top
10
repository,
I
tried
the
top
10
repositories.
It
was
not
easy
from
what
I
practically
tried
doing.
J
M
J
So
so
example,
I'm
gonna-
I
don't
know
whether
I
want
to
talk
about
this
at
this
meeting.
People
don't
want
a
pin
report
pin
they
said
they
trust
the
action,
it
doesn't
add
value.
The
second
comment
I
got
is
primarily
is
especially
dependable.
They
say
depend
about,
is
going
to
create
a
bunch
of
pr,
it's
going
to
add
work
to
the
maintainers.
J
H
Sure
I
just
want
to
say
if
I'm
gonna,
I'm
I'm,
probably
missing
some
context
here
in
terms
of
what
the
maintainers
actually
have
to
do,
because
my
understanding
was
that
the
osf
scorecard
works,
regardless
of
whether
maintainers
opt
in
are
there
some
things
that
they
need
to
opt
into,
or
it's
just
a
matter
of,
trying
to
get
them
to
do
things
so
that
their
score
is
better.
Yes,
so.
H
H
E
E
Yeah
yeah,
so
I'm
I
would
point
out
that,
because
we
are,
you
know
like
this
is
a
foundation
within
the
lf,
and
I
think
we
have
an
opportunity
here
to
reach
out
to
various
foundations
to
ask
their
maintainers
to
help
right.
So,
for
example
like
this
is
something
I
can
do
on
the
kubernetes
side
right,
so
I
managed
to
release
the
engineering
team
and
all
of
our
stuff
I
can.
I
can
put
under
right.
So
it's
like,
I
think
we
need
to
start
with
maintainers
who
are
already
partners
and
start
building
up
that
base.
E
This
is
something
that's
really
easy
like.
If
I
publish
scorecard
results-
and
in
fact
I
think
sorry
jeff
you-
I
think
you
are
naveen-
you
might
have
opened
an
issue
on
all-star.
That
said,
like
let's
eat
our
own
dog
food
and
I
posted
a.
I
posted
the
results
for
scorecard
right.
So
that's
the
kind
of
thing
that
we
can
break
down
into
individual
pr's
and
say
like
this
is
a
good
first
issue.
This
is
help
wanted
or
something
like
that
and
drag.
L
L
You
know
if
they're
hard,
because
but
if
they're
hard
but
worth
it
that's
great
if
they're
hard
because
they're
bad
criteria-
that's
not
good
now
granted
we
didn't
have
the
requirements
of
must
automate
without
any
help,
so
that
that
we
we
intentionally
simplified
things.
I
I
will
say
best
practices
badge.
We
actually
made
an
effort.
I
don't
remember,
I
think,
we've
implement
almost
all
or
all
these
scorecards
requirements,
and
I
now
get
to
shame
you
guys,
because
you
still
haven't
gotten
a
badge
you're
you're,
still
not
on
there.
Shame
on
you.
L
Now
good
news
is
project
alpha's,
probably
gonna
get
announced
next
week
I
mean
it's
been
existing
for
a
while
and
one
of
the
things
that
they're
intending
to
do
when
they
interact
with
specific
hot
super
high
critical
projects
is
they're
going
to
audit
them,
but
they're
also
going
to
try
to
help
get
them
best
practices,
badge
and
good
scorecards
measures
that
does
not
solve
it
for
everybody,
because
they're
only
going
to
focus
on
a
few
projects,
but
there
is
some
work
on
the
way.
More
is
better.
M
Cool
another
place
that
we
thought
about
trying
to
push
scorecard
for
consumers
if,
through
a
package
managers
hub.
So,
for
example,
if
someone
on
npm,
if
npm
were
to
adopt
the
npm
registry,
when
you
go
and
look
for
a
package
if
they
were
to
adopt
scorecard
and
show
the
scorecard
results
for
each
of
the
packages,
assuming
they
know
whether
what
the
origin
of
the
package
is,
that
would,
you
know,
put
scorecard
in
the
in
the
spotlight
for
everyone
to
to
look
at
and
and
in
fact,
in
our
team.
M
H
H
M
E
Yeah
so
they're
on
the
they're
on
the
video
faces
so
yeah,
I
think
tide
lift,
is
a
great
idea.
I
think
that
you
know
if
you
have
two
to
do
group
folks
here
or
we
can
definitely
chat
about
it,
chat
about
using
it
for
because,
like
I
think
that
you
know
this
is
there,
I
mean
there
are
a
bunch
of
different
fronts.
Right
you've
got
the
contributors.
You've
got
the
maintainers.
You've
got
the
sponsors
of
various
projects
right.
E
I
think
I
think
it
would
be
helpful
to
you
know
to
activate
various
company
resources
to
convince
people
that
this
is
a
good
idea.
I
think,
if
we're
doing
it
on
the
company
side
or
we've
got
company
contributors
that
are
kind
of
focused
on
those
efforts
or
making
it
easy
for
people
to
contribute.
In
that
way,
I
think
you
know
related
to
that
as
someone
who's
ramping
up
in
scorecard,
there's
an
incredible
amount
of
documentation
and
it's
super
awesome.
There
are
a
lot
of
issues
and
npr's
to
look
through.
E
N
So
just
hi
I'm
no
longer
with
gradle,
but
I
work
for
gradle
for
about
two
years
and
the
gradle
ecosystem
slash
gradle
itself.
I've
been
before
I
left.
I
was
working
pretty
heavily
on
trying
to
get
the
pentabot
support
to
work
for
gradle,
because
variables
depend
about
work,
currently
kind
of
sucks,
as
in
sucks
a
lot,
and
we
were
having
the
problem
of
how.
N
Theoretically,
didn't
encourage
you
to
lock
your
dependencies,
because
a
lot
of
these
automated
tools
like
depend
dependable,
try
to
rewrite
your
dependency
lock
files
in
ways
that
you
they
don't
know
what
they're
actually
doing
and
the
only
thing
they
can
do.
That
is
gradle
in
a
way,
that's
sane,
and
so
the
question
that,
like
you
know,
I
I
see
the
value
in
saying.
M
Okay,
so
that's
a
that's
a
good
point,
so
something
I
want
to
say
is
right
now
in
scorecard,
we
only
look
for
pin
dependencies
for
golang,
pip
and
npm,
so
any
other
ecosystem
language.
We
don't
currently
support
so
that
wouldn't
break
anything
on
gradle
today
and
and
we
have,
we
have
a
work
stream
in
the
best
security
practices
to
understand
for
every
package
manager.
M
M
E
So
a
point
that
a
point
that
david
made
on
a
separate
check,
I
think
it
was
related
to
licensing
or
something
around
gradation
right
like
if
something
is
bad.
How
bad
is
it
like?
It's
it's!
It's
not
a
binary.
You
know
it's
like
this.
Is
you
know,
you're
going
to
get
a
score
of
zero
you're,
going
to
get
a
score
of
10
right.
Four
four
package
managers
that
we
are
not
actively
supporting.
E
There
should
be
some
gradation
right.
If
it's,
if
it's
not
supported
at
all,
then
fine
right,
then
it
just
doesn't
work
if
it
is
supported
in
some
in
some
sense,
but
it's
an
alpha
state
right.
Maybe
that
is
maybe
that
is
a
modifier
for
the
score
right.
If
it's
something
that
we
expect
to
fully
support,
then
we
should
be
looking
at
it
like.
Are
we
actually
matching
the
security
concerns
that
we
have
right
so
for
gradle
doesn't
exist
today
like,
but
for
something
else
that
we
had
go
mod
right
like?
H
And
the
road
I'm
supposed
to
raise
my
hand.
Sorry,
the
raw
data
is
like
should
just
say
that
we
don't
support
it
right.
There
should
be
a
null
case
right
so
that,
if
you
actually
want
to
drill
in
you
know
that
there's
just
no
data
here,
as
opposed
to
like
a
score
that
looks
like
a
five
or
something
like
that.
E
H
M
M
L
So,
okay,
so
we
we,
we,
we
had
some
domain,
transferring
problems
kim
started
the
transfer
and
it
got
stuck
halfway
through.
I
think
we
figured
out
what's
going
on
and
I
think
we're
going
to
get
that
fixed
within
a
day.
So
sorry
we
had
to,
we
had
to
unwrap
and
figure
out
what
the
heck
happened
and
how
to
fix
it
so
yeah.
So
I
you
don't
know
for
sure,
but
hopefully
that's
all
going
to
work
out
very
soon.