AWS re:Inforce 2023 - Security in the Open: OSS and AWS (SEC201-L)

Aug 16, 2023

AWS re:Inforce 2023 - Security in the Open: OSS and AWS (SEC201-L)

Open source software (OSS) provides many foundational elements of the AWS Cloud and in the modern IT world. AWS is committed to raising standards for open source security by developing key security-related technologies with community support and by contributing code, resources, and talent to the broader open source ecosystem.

In this session, Mark Ryland, Director, Office of the CISO, AWS, and David Nalley, Director, Open Source Strategy \u0026 Marketing, AWS, assess the latest AWS work in OSS, including the open development of critical security-related technologies such as AWS libcrypto, s2n, post-quantum crypto, Amazon Corretto, Firecracker, and Bottlerocket. You will discover what AWS teams are doing to improve the security of the upstream OSS supply chain through contributions to the Open Source Security Foundation (OpenSSF) and more.

Learn more about AWS re:Inforce at https://go.aws/3N9286k.

Subscribe:
More AWS videos - http://bit.ly/2O3zS75
More AWS events videos - http://bit.ly/316g9t4

ABOUT AWS
Amazon Web Services (AWS) is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers — including the fastest-growing startups, largest enterprises, and leading government agencies — are using AWS to lower costs, become more agile, and innovate faster.

#reInforce2023 #CloudSecurity #AWS #AmazonWebServices #CloudComputing

Content

2.033 -> The past 12 to 18 months, like,

5.3 -> no point in my previous 20 years involvement

8.067 -> in open source has really driven home

10.933 -> just how pervasive and ubiquitous open source has become.

17.233 -> Open source is truly everywhere.

19.5 -> And I know that it's in my watches.

22.867 -> I know that it's in the cars that I drive.

26.233 -> It's the washing machine in my house,

28.633 -> and of course all over the software on the computers that we operate.

34.4 -> I've known that, frankly, for 20 years.

36.733 -> I knew that open source was everywhere,

39.133 -> that it was important.

40.6 -> And of course, open source is important to AWS.

43.833 -> We build tools atop it.

45.367 -> We build services atop it.

47.167 -> Our customers love it.

48.967 -> And so we've got a vested interest in the broader security

53.867 -> of open source in the landscape that we operate in.

60.2 -> But as I said, the past 12 to 18 months

62.233 -> have been really a huge change in people

66.9 -> recognizing just how ubiquitous it is.

70.333 -> And so Synopsis, who provide the Black Duck

74.733 -> software composition analysis tool,

77.7 -> they're telling us that 96% of codebases

80.867 -> that they see contain open source.

84.8 -> 96%.

88.333 -> I've always known that open source has been ubiquitous, but 96%?

95.7 -> So I want to spend some time talking about open source,

101.2 -> how AWS thinks about it.

103.533 -> I want to say that it's not just important,

105.767 -> but talk a little bit about why it's important

108 -> and how we engage in open source communities.

112 -> I think the why is important,

113.4 -> because it probably applies to most companies,

116.833 -> and I want to explain our commitment and our strategy.

120.867 -> AWS has this long history of benefiting from open source.

126.3 -> AWS would not look like it does today without open source.

131.167 -> If you'll remember EC2, it was built atop the Xen hypervisor.

137.533 -> S3 was originally built atop Apache Tomcat.

142.633 -> They were the foundational layers that allowed us to innovate quickly

146.2 -> and deliver value to our customers.

149.833 -> And we think that open source is much better

154.433 -> in terms of being able to provide those foundational layers

159.333 -> that allow us to innovate and deliver value.

161.7 -> No one wants to reinvent the wheel and write another web server.

165.933 -> We have a number of very good open source web servers

169.067 -> that allow us to not have to spend the time to re-implement that.

175.033 -> Of course, that means that we need to have a very healthy,

180.7 -> a very sustainable open source foundation to build atop.

185.167 -> And healthy means a couple of different things, right?

189 -> We obviously, we want secure code.

191.433 -> We want well tested code that operates well.

194.6 -> We also want the communities that are building that code

197.833 -> to be sustainable and to be healthy.

200.8 -> We don't want the one person in Nebraska

203.8 -> holding up the entire Internet.

207.267 -> And so when we look at--when we're looking

210.267 -> at how we pay attention to open source,

214.8 -> we recognize that it's important to our business,

217.233 -> it's important to our builders,

219.5 -> and we build, obviously, plenty of things on top of it.

225.133 -> But it's not just important to AWS.

227.467 -> It's important to our customers.

230.433 -> Many of our customers tell us that they have open source

233.867 -> first mandates in their business.

238.1 -> Meaning that when they're choosing a new technology platform,

241.567 -> that they are defaulting to open source if one is available.

245.9 -> And so with customers repeatedly choosing open source,

249.833 -> asking us to help with their open source workloads,

253.467 -> and whether that's a database server,

256.433 -> whether it's AIML platforms or container orchestration engines,

263.333 -> we have to make sure that those workloads run

265.667 -> really well on top of AWS and for our customers in general.

272.8 -> Open source also is important to the world.

276.767 -> It has become a common foundation that we're all dependent upon,

281.967 -> which means that we have somewhat of a shared destiny,

285.767 -> because we're all depending upon open source,

288.133 -> because open source is ubiquitous.

292.667 -> We have a lot of conversations.

294.367 -> Mark and I get to speak to customers frequently,

297.767 -> and customers are continuously asking us,

302.1 -> “Tell us how you think about open source.

304.333 -> How are you securing your supply chain?”

307.467 -> We're having lots of software supply chain security conversations today,

311.967 -> and that really comes down to two questions.

316.967 -> The first is how are you consuming open source safely?

321.967 -> What constraints are you putting in to make sure

325.167 -> that open source is being consumed in a responsible manner?

329.033 -> And then also, how are you taking care

331.533 -> of the software development process

335.567 -> to ensure that all of these things that you're ingesting are secure?

340.333 -> And people are lumping both of those things

344.333 -> into our software supply chain security conversations.

349.433 -> And so we want to talk a little bit about that as well

352.933 -> and show you some of the things that AWS is doing,

356.5 -> may not be a perfect fit for other folks,

358.2 -> but at least it'll be very transparent

360.533 -> in how we handle open source and how we think about that process.

365.6 -> Mark, do you want to talk about some of those conversations?

369.333 -> Yeah, good morning, everyone. It's great to be here.

372.6 -> This presentation is very broadly

375.633 -> about how AWS works with the open source community

377.967 -> to make it stronger, healthier and more secure.

380.6 -> But we thought it would make sense to at least briefly talk

383.4 -> about how we consume open source and that conversation,

387 -> although a brief part of this overall talk,

388.633 -> we could do a whole hour just on this topic,

391.1 -> will at least give you some thoughts about both how we operate,

394.2 -> but thoughts about how you as well could operate.

395.833 -> There's not one perfect way to do this,

397.2 -> but we think we have some learnings we'd like to share.

400.767 -> So just briefly, in terms of secure consumption,

404.6 -> we very much take a federated approach to this topic,

406.833 -> as we do with many other topics.

408.2 -> We don't highly centralize really anything at AWS,

412.767 -> but we still have central teams that support certain core functions

415.667 -> to make sure that the teams that have sort of direct

418.267 -> or immediate responsibility are doing their job well.

421.767 -> And for us, open source consumption begins in the engineering teams

425.2 -> that need--that decide to use open source.

427.367 -> So the consumers of open source take that core responsibility

431.4 -> for the software artifacts they're using,

433.533 -> whether they develop them themselves

435 -> or whether they import something from the outside world,

437.033 -> it's their responsibility to do that in a safe, sane and secure fashion,

441.033 -> with the support of a bunch of other teams.

442.5 -> But still, the core responsibility exists in that initial consumer.

447.967 -> And in order to make sure that we have ownership of these artifacts

451.067 -> once they're brought in,

452.767 -> we place that responsibility on sort of that initial consuming team.

456.767 -> They can hand it off later, perhaps, if that makes sense.

459.4 -> But some team has to really own the health

462.233 -> and maintenance of that core library or what have you,

464.867 -> and that's the builder team.

467.433 -> They need a lot of support to do that well,

468.833 -> and that's where our Builder Experience team,

470.4 -> which is a central team, comes in.

472.133 -> This is the team that runs the core code repositories,

475.633 -> build servers, build pipelines,

477.6 -> as well as all the deployment capabilities

479.767 -> and a lot of centralized testing that runs on every single code check

483.067 -> in everything from unit tests and so forth.

485.567 -> But security tests and code scans, static code analysis,

489.2 -> software composition analysis,

490.467 -> all these tools are run in a central service fashion

493.667 -> by the builder experience team.

495.733 -> So that means that any other organization that wants to use

499 -> this open, say, an open source library,

500.367 -> the first thing they're going to do

501.6 -> is they're going to look to see, “Hey, is anybody else using this?”

503.733 -> Just like they would want to reuse code that's internal only,

507 -> they're going to want to reuse open source code as well,

509.233 -> because that means someone's taken initial responsibility for vetting,

512.533 -> maintaining and updating that system.

514.233 -> And so this is where that other team would go,

516.467 -> would go to the central code repository and tools,

519.7 -> find that capability or that library

522.633 -> or that source code and progress from there, again,

527.533 -> with that sort of federated ownership and control.

530.867 -> And then finally, we have a security team,

532.667 -> a central security engineering team, especially on the proactive,

536.4 -> what we call proactive security or Apse,

538.667 -> which does run a lot of the central tooling to make sure that we're,

541.767 -> again, using and consuming and deploying systems and code

544.3 -> in a very safe fashion across the board,

546.867 -> including the open source components.

548.833 -> And so the Central Security engineering team

551.6 -> not only runs a lot of the security checks

553.567 -> in that central builder environment

557.233 -> and maintains both proprietary and third party

561.033 -> and open source security scanning tools and so forth.

564.033 -> They run, for example, this is a little off the topic,

566.933 -> but a canary service.

569.267 -> So when you write your code, you also write security

572.2 -> and variant types of checks, which then the security team

574.733 -> has a service which runs those constantly to make sure

576.933 -> that certain security invariants of your service in production

581.067 -> are constantly doing the right thing,

583.167 -> returning the right result, the expected result from any call,

585.9 -> typically around authorization,

587.067 -> but lots of other security invariants that you want to maintain.

590.267 -> You build essentially tests that run

592.433 -> constantly against the production environment.

597.3 -> Kind of helping hold this all together

599.133 -> is our open source program office.

602.067 -> They provide kind of the general interface

604.7 -> to sort of the correct and proper and healthy interaction

608.167 -> with the outside world, along with David's team as well.

611.233 -> They're the ones that are doing things like making sure

613.167 -> that we have good relationships with the right outside builders,

617.7 -> sponsoring and funding things that make sense.

619.9 -> We'll talk more about security related funding later in the talk,

623.567 -> and in general, creating that healthy interface

626.033 -> between AWS and the broader open source community

628.733 -> to make sure those lines of communication,

630.833 -> those relationships are there to support the overall health

633.667 -> of this of this environment,

635.067 -> and again, using open source in a secure fashion.

638.5 -> And we'll talk in a minute about working upstream.

640.933 -> So another aspect of all of this is if we do see need to make changes

644.733 -> or improvements or security fixes or what have you,

646.933 -> a key part of what we're going to be doing

648.533 -> is making sure that those get pushed upstream as well.

653.267 -> So, after a little detour, if you will,

656.933 -> although a very important one on consumption,

658.6 -> we'll go back to sort of how we think

659.967 -> about--how we interact with the broader world in open source.

663.533 -> And we'll focus on these three pillars: work upstream.

669.3 -> That means when you're working with something

670.833 -> where you're not the kind of primary creator,

674.467 -> make sure that you are interacting with that original source

677.667 -> in a way that is responsible

679.433 -> and contributing to the common good there.

681.967 -> Release tools, and effectively this is be the upstream in many cases

686.1 -> when you have things that the rest of the community can benefit from,

689.033 -> put them out there so others can benefit.

691.367 -> And then we'll talk also about financial support as well.

695.167 -> We'll start with the work upstream.

697.4 -> So if we think if we take this kind of long term and community

703.333 -> oriented approach to working in the open source world,

706 -> we can benefit not only ourselves but the broader community.

708.667 -> And we've been doing this for a long time

710.567 -> and increasingly more and more over the years.

713.967 -> I'll dive into a few of these.

715.133 -> We'll dive into a few of these examples in more detail,

717.2 -> but just to cover a few in a more kind of quick and anecdotal way,

721.833 -> I want to call out Xen project.

723 -> This was, as David mentioned, EC2,

725.533 -> one of our first and most foundational services

728.333 -> originally launched on the Xen hypervisor.

731.367 -> This is back in the days when Intel processors

733.867 -> didn't have support for hardware virtualization,

737.167 -> and people may remember some funky things that were done in those days.

740.967 -> Xen was really pioneering with this notion of Paravirtualization.

744.833 -> Raise your hand if you remember Paravirtualization.

746.7 -> It's kind of dead, and it needs to be dead, because it had some issues.

750.7 -> But it did an amazing job,

752.5 -> and we worked very closely in that world of Xen

755.333 -> to make sure that we were deeply involved with improvements,

758.2 -> patches and so forth.

762.367 -> Now we've been gradually deprecating our use of Xen,

765.033 -> as probably many of you know,

766.2 -> and moving to KVM based, the nitro hypervisor.

769.8 -> We're still active in the Xen community,

771.333 -> and one of the last kind of major contributions we made to Xen

774.667 -> was in the spectrum meltdown era,

777.033 -> when we realized that a lot of shared state at the processor level

781.267 -> could lead to certain kinds of side channel issues.

784.5 -> And Paravirtualization, in particular,

787.133 -> was very problematic in that regard.

789 -> It was very problematic that the kind of shared state

792.267 -> between the kernels and drivers in the paravirtualized instances,

797.033 -> that you could have problems of the type

799.233 -> that are manifested in Specter meltdown.

802.6 -> So we actually created an internal technology

804.7 -> to create a kind of shim layer,

806.3 -> so that the operating system that's being hypervised

809.867 -> thinks it's being paravirtualized,

812.067 -> but actually there's an HVM hardware virtualization

814.767 -> layer sort of under the covers.

816.233 -> So you're essentially creating a sort of fake copy

819.067 -> of some Xen internals on the VM side

822.267 -> and then actual HVM capability between the guest and the hypervisor.

828.233 -> This is a technology we call Vixen, and we did push this upstream,

831.567 -> and so now any consumer of--it was modified slightly,

835.3 -> but it did become kind of the standard now,

837.4 -> so that Xen users can run old-fashioned,

840.333 -> never updated operating systems that expect Paravirtualization,

843.833 -> but actually are using harbor primitives to do that.

847.6 -> There's many other great examples here

848.967 -> before we get into some of these others.

850.567 -> The one other one I want to call out very recently in the KVM world,

855.733 -> those of you who are familiar with operating system

858.367 -> and hypervisor security, you might be familiar with something

860.9 -> that Microsoft calls virtualization based security.

863.833 -> So for the Windows operating system and the Hyper-V hypervisor,

868.267 -> they've developed some technology

869.5 -> that they can sort of take parts of Windows

871.533 -> and run it in a separate--kind of like a separate VM.

874.133 -> It's not exactly a separate VM,

875.467 -> but it's a hypervisor protected memory space,

879 -> and that is designed to protect against certain kinds

881.7 -> of cross process attacks, essentially, that might cause trouble

885.7 -> with the things like the local security authority in Windows LSA,

889.133 -> which maintains all of your passwords and clear text in memory,

893.233 -> for example.

895.267 -> Now the problem is that that's a proprietary Microsoft technology.

898.8 -> They released some information about how they did that,

900.8 -> but it's definitely not open source.

903.467 -> We developed a VBS capability for KVM,

906.367 -> which we just recently started pushing upstream.

908.967 -> So anyone who uses the Linux--is in the Linux ecosystem,

912.5 -> using the KVM hypervisor,

914.133 -> will be able to run these sort of advanced and proprietary

916.567 -> Windows features and do that on an open source basis.

919.433 -> So we're very excited about that.

921.7 -> Let's move on to some specifics here, and we'll start with OpenJDK.

926.133 -> So we've had a long history with Java.

927.667 -> We're a big Java shop.

929.033 -> Continue to be.

930.733 -> And back now, five years ago, 2017 timeframe, began to see a future

935.667 -> in which we really felt the need

936.933 -> to take a lot more ownership for Java and our use of Java.

941.6 -> And in the 2017, 2018 time frame realized

943.967 -> we're not the only large enterprise

945.467 -> that is a little bit concerned about the future of OpenJDK.

948.967 -> There was a change of ownership, as you may recall, in the industry.

951.2 -> I won't name any names, of the Java environment,

954.9 -> and there was a general concern

957.167 -> that the open version might need some additional love and care

961.067 -> and really become more of a full community effort.

963.533 -> So we joined in that effort.

965.067 -> We created our own Java distribution, we call Corretto,

969 -> and since then we've really invested heavily in the OpenJDK world,

972.333 -> and we release our Corretto capabilities and runtime to the world for free.

976.267 -> You're welcome to use it.

977.367 -> It's fully supported by our support organization

979.4 -> and by our engineering processes.

981.667 -> I won't go through all the different things on the timeline

984.133 -> for the sake of time.

985.2 -> You can download the slides, but basically it's just the point

987.967 -> we're making is that we've decided to really help the community

993.267 -> jointly own the destiny and the quality

995.233 -> and the features of OpenJDK going forward

997.267 -> and making some very, very deep investments in that.

1001.4 -> And I'll hand off to David for some more topics.

1004.933 -> I just want to call out Corretto

1006.5 -> has done amazing things for our customers and for the users.

1011.267 -> Specifically, we just saw New Relic tell us

1015.167 -> that Corretto is the most widely consumed

1019.2 -> OpenJDK distribution, which is mind boggling,

1023.067 -> but it tells me that customers are actually finding value

1026.667 -> in what we're providing.

1028.367 -> So I'm super excited about that.

1030.6 -> But I'm a little more excited about Rust.

1033.433 -> And how many folks know what Rust is?

1037.067 -> Okay, so Rust is a new programming language,

1040.267 -> and I say new, it's been around--

1042.167 -> David, does the world need another programming language?

1044.667 -> The answer is—

1045.8 -> Yes, and more security tools.

1047.033 -> Yes, it actually does.

1048.267 -> And he'll explain why.

1050.833 -> So Rust is a new programming language, and I use the term new relatively.

1055.767 -> It's certainly newer than C and Java,

1058.867 -> and it has come about offering the performance of C,

1064.633 -> but with a number of additional assurances.

1068.167 -> So the biggest value from a security perspective that we see with

1072.267 -> Rust is thread safety and memory safety.

1075.767 -> And we're going to talk a little more about memory safety

1077.6 -> in a little while.

1078.867 -> But when we were looking at operating things at scale,

1083.1 -> Mark said we're a large Java shop,

1085.433 -> and we started paying attention to Rust in 2017.

1090.733 -> In 2018, we shipped Firecracker, which was written primarily in Rust,

1096.7 -> and that is an open source operating system

1100.867 -> that's really permitting serverless technology.

1103.9 -> So if you're running AWS Lambda, Firecracker is there,

1108 -> we've released that as an open source project for people to consume.

1113.5 -> And that was the first visible notice that we gave the world

1117.433 -> that we were paying attention to Rust.

1119 -> We had been using it for some internal things already prior to that.

1123.6 -> More recently, we launched a new Linux distribution called Bottlerocket,

1127.867 -> and Bottlerocket is heavily Rust language focused

1134.1 -> and is designed to provide a really thin,

1138.067 -> small security surface for running containers.

1142.533 -> And so we've also made that open source.

1146.167 -> Folks can download and make use of that already.

1150.7 -> In 2019, we announced that we were sponsoring the Rust Project.

1156 -> In 2020, we started hiring a number of Rust maintainers,

1160.1 -> because we recognized that Rust was going to be important to how AWS

1165.167 -> was going to develop in the future.

1167.9 -> So we started building up a team of folks who were already invested

1172.1 -> in the Rust programming language,

1174.467 -> who had already made substantial contributions

1176.5 -> and had leadership positions there.

1179.933 -> Shortly after that, we helped found, with a number of other stakeholders

1185.4 -> in the community, the Rust Foundation.

1188.5 -> And today, EC2 looks at Rust as its language of choice

1193.9 -> for security sensitive applications such as nitro enclaves.

1199.533 -> And so we think that that Rust is incredibly important

1204.733 -> to what's going to be the future of a number of different workloads

1208.7 -> inside AWS.

1210.733 -> And we're working, we're heavily working.

1212.767 -> We've got two teams who are focused on upstream contributions

1217.233 -> into the Rust programming language,

1219.067 -> because we think that there is so much benefit not just for AWS

1223.533 -> in how we build our tools and our services,

1227.533 -> but for the rest of the world,

1228.933 -> because we get into things like memory safety.

1233.433 -> But Mark and I, we just talked about programming languages,

1235.933 -> and I won't talk about a third,

1238.233 -> because maybe the world does finally have enough programming languages.

1242.167 -> I want to talk a little further up the stack with Kubernetes.

1246.333 -> And Kubernetes is really a workload orchestration

1250.4 -> that the primary workload is containers,

1254.133 -> and it has become incredibly successful.

1257.533 -> And it's become successful by a number of different measures,

1261.133 -> the number of people contributing.

1263.367 -> There are literally thousands of people

1265.5 -> who work on every single release of Kubernetes.

1269.467 -> The number of workloads that now assume that Kubernetes

1273.067 -> is going to be the underlying layer that they're operating on.

1276.433 -> And I can't tell you the number of new tools

1279.3 -> that I look at that presuppose that they're going to be operating

1282.733 -> in a Kubernetes environment.

1285.567 -> We obviously recognized this when our customers were telling us

1288.267 -> that Kubernetes was important.

1290.133 -> We have the EKS service and obviously provide managed Kubernetes.

1296.667 -> But we recognized a need really early on that

1299.933 -> we needed to get involved in Kubernetes

1302.067 -> and the rest of that Cloud Native Computing Foundation arena.

1306.4 -> And so we've been getting involved in places like Container D,

1310.067 -> etcd, Nerd Cuddle, all of the surrounding technologies

1314.333 -> that help make Kubernetes so useful and so helpful,

1318.9 -> because Kubernetes is not just one thing.

1321.733 -> It's essentially using a driver model,

1324.7 -> allowing people to plug in different things,

1326.867 -> like different network controllers, different scheduling technology.

1333.233 -> And that is one of the reasons that it's been so successful

1336.367 -> is that ability to plug in things.

1337.867 -> But that means lots of help is needed on the outside.

1342.533 -> So etcd, Container D, etcetera,

1345.8 -> are contributing technologies to that success.

1348.433 -> And we have heavily invested there,

1350.8 -> taken leadership positions in technical steering committees,

1355.7 -> in the governing board and a number of other places.

1359.5 -> And also released some of our own tooling,

1361.333 -> where we recognized gaps that our customers are pointing out to us.

1364.267 -> So Carpenter was recently released recently, a year ago,

1370.5 -> was recently shown and provides a lot of value for our customers

1375.133 -> in trying to scale things on Kubernetes.

1378.8 -> But we also recognize that Kubernetes does not exist

1382.167 -> on code contributions alone.

1384.5 -> So we've done a couple of other things.

1386.667 -> One is, despite how popular Kubernetes is

1390.733 -> and how fast it's innovating,

1392.933 -> that's creating some upgrade fatigue with customers.

1396.567 -> And so they don't want to upgrade every six months.

1399.733 -> They've asked us for help, and we, along with others in the community,

1402.667 -> are working on figuring out a longer support time frame for that,

1407.633 -> because customers want to be able to actually operate something,

1410.767 -> not just be in an infinite upgrade loop.

1414.733 -> We're also, though, realizing that there needs to be infrastructure

1419.233 -> to actually test Kubernetes in advance.

1421.8 -> And so we committed millions of dollars in cloud credits

1425.767 -> every year for continuous integration for the types of testing

1431.7 -> that ensure that when you deploy a new version of Kubernetes,

1436.1 -> that hopefully it will be pain free.

1438.733 -> We've been doing that, as well as helping

1441.5 -> with their release infrastructure now

1443.867 -> and getting involved there to make sure that, you know, again,

1448.7 -> the project does not sustain itself on code alone.

1454.067 -> But that's not the only thing we should be doing, right?

1457.7 -> We talked a little bit about adding features.

1461.467 -> Mark talked about adding features to KVM,

1466.867 -> improving security on Xen, and that's important.

1470.533 -> And I think that AWS has an obligation or responsibility

1475.5 -> to release the security improvements that it has.

1480.067 -> And, Mark, do you want to start talking about that?

1482.8 -> Yeah. So in many ways, again, as a shortcut,

1485.567 -> you could say work upstream is one thing.

1487.733 -> Be upstream is another thing.

1489.3 -> Of course there's an overlap and a dynamic quality to that.

1492.3 -> But in this case, what we're saying

1494.367 -> is we have developed technology from scratch

1497.2 -> that we realize is very useful for--I say from scratch.

1500.5 -> I'm sure there's open source libraries inside of those,

1503.167 -> but basically significant major projects

1506.233 -> that we then want to release to allow others to benefit from,

1508.833 -> even when they're not using our cloud platform or any of our tools.

1512.9 -> And so we want to talk about a few of those in this session as well.

1516.433 -> We'll dive into, I think, three of those,

1519.1 -> but I'll call out a few

1520.3 -> that don't have their own separate slides in this overview slide.

1523.6 -> So a launch from August of last year,

1526.8 -> Open Cybersecurity Schema framework, OCSF.

1531 -> This is actually a set of supporting open source tools,

1534.267 -> but the core release is actually of a standard

1537.333 -> which allows security tools to interoperate

1539.967 -> in a much more seamless way.

1542.233 -> When we would talk to customers

1543.6 -> and working with a lot of partners in the security space,

1546.2 -> what we heard over and over again was my security teams

1549.167 -> spend too much time on data munging and data cleansing.

1552.767 -> They're doing this kind of repetitive stuff.

1554.6 -> They're writing tools or they're doing manual things.

1556.533 -> They're cutting and pasting between multiple open windows on a screen.

1559.867 -> Just crazy stuff to try to get security tools

1562.367 -> to actually work together

1563.967 -> and to do that basic kind of function you need to do often,

1567 -> which is I need to do sort of a join across two data sets.

1569.967 -> And it was often very, very hard, if not impossible.

1573.333 -> So what we realized was if we could create a standard

1576.267 -> for how tools communicate

1577.667 -> with one another, there'd be a huge benefit to that.

1580.767 -> So now we launched this last August actually at Blackhat

1584.5 -> with about 20 other partners all signing up to support OCSF.

1588.5 -> Now I think there's up to 60 or 70 companies

1590.533 -> who are all committed to either emitting or consuming

1594.467 -> OCSF records from their security products.

1598.267 -> And that will make it much easier going forward for security teams

1602.067 -> to manage the data that's flowing in and out of these tools.

1605.6 -> We also use the OCSF format as the native format of the Security

1609.967 -> Lake product that we just launched I think a week ago

1613.1 -> and was in the keynote yesterday.

1615.6 -> So any tool that can emit OCSF can natively feed their data

1620.533 -> into our security lake.

1622.267 -> And that was not an accident, by the way,

1624.067 -> that we worked on both a standard

1625.833 -> and a service together that supports the standard.

1628.233 -> So that's a really, I think, a really interesting and impactful one.

1631.6 -> David already mentioned Bottlerocket.

1632.967 -> Bottlerocket you can think of as a secure

1635.367 -> Linux distribution focused on container security.

1638.1 -> So for example, it has a read only file system.

1641.067 -> There's no reason why file systems need to be updated at the OS level,

1644.833 -> if the only thing it's doing is running containers

1647.1 -> that are running virtualized file systems on top.

1649.733 -> So and it has many other such attributes of very locked down, very secure

1654.667 -> Linux foundation for running container environments.

1658.5 -> Firecracker we already mentioned.

1659.833 -> Firecracker implements a technology that are called microVMs.

1664.5 -> So again, we don't trust container boundaries as a security boundary.

1669.033 -> In general, there's very bad track record of containers

1673.267 -> being fully secure

1674.633 -> in terms of the ability to escape from a container.

1676.5 -> They really weren't designed for that, so there's no blame there.

1679.6 -> So we strongly believe in using harbor based virtualization

1683.067 -> whenever you have a multi-tenanted or any workload

1686.067 -> where you need strong isolation.

1688.367 -> The problem is that VMs typically, a typical virtual machine

1691.267 -> takes a while to boot:

1693.167 -> seconds, maybe a minute, because they're big and complicated.

1696.7 -> So Firecracker implements a microVM technology

1700.333 -> in which a full KVM virtual machine can be booted

1703.667 -> and executing user space code in less than one eighth of a second.

1707.4 -> So 125 milliseconds is the design goal for Firecracker.

1710.633 -> We've met that consistently over time,

1713.033 -> and that means that you can now launch

1714.833 -> VMs as quick as you can launch a container essentially

1717.933 -> or close enough that you can use that

1719.5 -> as a very foundational property of your container

1722.067 -> based or function as a service workload.

1724.167 -> So we use Firecracker underneath Lambda and underneath our Fargate service,

1728.733 -> but we also release it to the world.

1730.367 -> And there's a lot of other vendors now who use Firecracker

1733.567 -> in their container runtime environments,

1735.8 -> and we're really excited for the success of that.

1740.1 -> I think you were going to call one of these out before I move on.

1742.1 -> Yeah, I’ve got a favorite.

1743.267 -> I do have a favorite on this slide, and it's trusted language extensions.

1748.333 -> So PostgreSQL, the open source database,

1751.5 -> has a wonderfully vibrant extension community,

1755.9 -> and that allows Postgres to change from a relational database

1761.567 -> to a vector database to something focused on geospatial

1765.6 -> and a host of other things.

1767.3 -> There are literally hundreds of extensions to PostgreSQL,

1771.367 -> the database itself.

1773.367 -> And we recognized from some of our own pain,

1777.467 -> and while it didn't directly impact our customers

1779.967 -> because of defense in depth, we saw that a number of folks

1783.567 -> were calling out the extension space as an attack surface

1788.733 -> that would allow them to do nefarious things to PostgreSQL databases,

1794.5 -> true in hosted environments as well as self-managed.

1798.333 -> And so we created trusted language extensions

1802.433 -> and released that as open source.

1805.633 -> We did that at re:Invent last year.

1807.267 -> And I'm excited about this,

1808.533 -> because not only does it solve a problem for us,

1812.567 -> and we could have just solved that problem,

1814.667 -> but we released this because we recognized

1817.4 -> that everyone should have a more secure and a more safe PostgreSQL.

1822.433 -> So the trusted language extensions

1824.367 -> are probably my favorite thing on this slide,

1827.8 -> because it's something that we've seen a significant problem,

1832.433 -> identified that problem,

1834.133 -> and then worked to not just shut down the specific issues,

1839.233 -> but to create a safer environment to run those extensions in.

1843.633 -> I'm super excited.

1845.167 -> I'm really excited by seeing

1846.433 -> how many people are adopting trusted language extensions

1849.967 -> as the environment in PostgreSQL that have nothing to do with AWS.

1854.533 -> That's awesome.

1855.7 -> That's a great story.

1857.2 -> So we'll dive into a couple of these.

1859.867 -> Open quantum safe is called out here, OQS,

1862.467 -> and we'll talk about that in the context of S2

1864.433 -> and some other crypto stuff.

1865.733 -> And then Cedar and maybe I think we have one other example here

1868.467 -> in terms of our decision to work in the open

1872.367 -> with core technologies that we develop.

1875.2 -> So you can imagine you run a cloud platform, encryption super important.

1879.667 -> It's one of the fundamental properties of data isolation,

1882.433 -> data security that customers rely on, that we rely on.

1885.7 -> So you really want to be constantly on the cutting edge of cryptography

1891.567 -> and of encryption technologies across the board.

1894.333 -> Customers, obviously, they're running applications on top of our stack.

1897.433 -> They want super-efficient systems

1900.167 -> with minimum CPU and memory utilization,

1902.3 -> but they want state of the art technology underneath.

1905.367 -> So we've been on a journey now for a number of years

1907.6 -> to develop technology in this space

1910.667 -> and to open source the technology we develop,

1912.633 -> because we believe it can benefit the broader community.

1915.3 -> I'll start with s2n.

1916.467 -> s2n was one of our first forays into this general space.

1920.967 -> It originally stood for signal to noise.

1922.5 -> I'm not sure if we even spell that out anymore, we call it s2n.

1925.9 -> But you can think of s2n as a very stripped down,

1928.9 -> very minimalistic, very feature poor, intentionally,

1932.667 -> implementation of the TLS protocol.

1935.3 -> Feature poor meaning that TLS has a ton of features

1937.767 -> that most people never use,

1939.233 -> and but to implement those features takes a lot of code

1943.133 -> and therefore introduces the possibility of more bugs.

1946.367 -> The wakeup call for us and I think for a lot of people in the industry

1949.367 -> was the Heartbleed zero day.

1951.7 -> Remember the Heartbleed one?

1952.767 -> Raise your hand if you had a bad day on the Heartbleed day.

1956.5 -> We did, too, although we were able to patch

1958.133 -> a massive global fleet of load balancers in less than 24 hours,

1961.1 -> we still had literally hundreds of thousands of hosts

1964.033 -> that had to be patched in our ELB service.

1968.667 -> But that was a wakeup call, because we looked at like, okay,

1970.567 -> what's the root cause here?

1971.7 -> Well, it's a bug in OpenSSL.

1973.267 -> And okay, software has bugs, but it was a pretty painful one.

1978.467 -> But what about OpenSSL?

1979.567 -> Oh, it's 300,000 lines of C code.

1983.1 -> It's old, it's Crufty.

1984.7 -> It's got--I mean, God bless the community for keeping it up.

1987.7 -> And we now we've been financially supporting them ever since,

1991.033 -> and it's done a ton of good for the industry,

1993.533 -> but it's not what we felt really good about

1996.2 -> in terms of relying on as a core technology

1998.533 -> for very fundamental security properties of our cloud.

2002.1 -> So since then we've been kind of on a journey

2004.933 -> to both implement a replacement and substitute

2008.633 -> that in and use it as well as release that to the world.

2011.533 -> s2n was one of the first steps there.

2013.667 -> So it's, again, just implements the TLS part of the protocol,

2017.367 -> still uses OpenSSL for the cryptography parts

2020.233 -> of the handshake and the encryption.

2023.567 -> That was some years ago.

2025.367 -> s2n is an interesting example too, because this was before

2028.133 -> Rust was kind of up and running and popular, so it's written in C.

2032.767 -> However, it's written in a very strange and idiomatic C

2035.967 -> that looks just like Rust,

2037.267 -> because you can't do any direct memory access.

2040.6 -> It requires all these kind of indirections.

2042.733 -> And we have formal tests and proofs that show that if any developer

2046.433 -> does a check in that's not using the proper memory handling functions

2052.367 -> that are inside of s2n, sorry, your code will get rejected.

2056.8 -> So still using the C language, but using it in a very carefully

2060.6 -> crafted and memory safe fashion.

2062.933 -> A couple of other really interesting facts about s2n.

2064.9 -> First of all, it's a project that had, I think at the start,

2068.067 -> maybe a little bit more now, about 20,000 lines of code,

2071.033 -> 80,000 lines of tests.

2072.633 -> So it's a very, very test centric, test heavy project.

2078.133 -> And it was the first test, first release to the wild,

2080.733 -> as far as I know,

2081.9 -> at least of any significant piece of code,

2083.5 -> in which formal verification was part of the build

2087.167 -> and the test and release process.

2088.633 -> So all the people we hire,

2090.5 -> and you've probably heard in many talks from AWS,

2092.567 -> a group we call the Automated Reasoning team

2095.367 -> or these formal verification capabilities,

2098.8 -> a branch of computer science that has been a bit obscure.

2101.4 -> It's been around for a long time.

2103 -> It's not obscure anymore, at least as far as we're concerned.

2104.967 -> We're using more and more we're using the tools

2106.967 -> and techniques of formal verification to prove the correctness of code.

2111.533 -> In s2n, if you go to the GitHub repository

2113.733 -> and you look at the build instructions and you download and try to build it,

2116.3 -> you're going to actually download a bunch of formal proofs

2118.767 -> about the correctness of various parts of that code.

2121.1 -> Again, it doesn't mean the code is bug free necessarily,

2122.933 -> but it's a much higher standard than we've traditionally done

2125.967 -> for a lot of these systems.

2127.6 -> So that was a big and important foray into this space,

2131.567 -> but we didn't want to stop there.

2132.7 -> So subsequently we've also open sourced our own libcrypto,

2137.5 -> so now we're giving you an open source reimplementation

2140.467 -> of the core cryptographic primitives you need for your network,

2145.4 -> as well as other use cases

2147.967 -> that are traditionally done in the OpenSSL library.

2151.667 -> I won't go on and on about libcrypto, but it's out there.

2155.467 -> One of the key things we're doing with libcrypto

2157.267 -> is we're taking on the burden of FIPS validation.

2160.2 -> That's one of the kind of things

2161.867 -> that people often expect of their cryptographic libraries.

2164.633 -> They want that third party validation.

2166.1 -> And interestingly, even around the world,

2168.333 -> we still hear people are very happy with FIPS validation,

2170.967 -> even though it's technically a US government standard.

2174.9 -> And but it's hard for an open source team to do that.

2177.967 -> It's expensive, it's time consuming, it's frustrating,

2180.133 -> it takes a long time.

2181.6 -> It's almost you almost kind of require commercial interest

2183.9 -> and commercial commitment to really kind of go through the trouble,

2187.067 -> which many companies do.

2188.433 -> But we're doing that on behalf of the open source users

2190.8 -> of s2n and of libcrypto

2193 -> We're taking that that through FIPS validation,

2195.867 -> and we'll keep that up to date as time goes on,

2197.767 -> which is kind of the hard part.

2198.867 -> Often you get it through and then you kind of like relax and move on,

2202.1 -> and then your code gets out of date.

2203.767 -> And so you get into this bad cycle.

2206.133 -> So we're doing that with libcrypto.

2207.767 -> And the final thing I want to call out that's just briefly referenced

2210.867 -> in this slide, and we could spend a whole hour on it is

2213.533 -> Post-quantum cryptography.

2214.7 -> So we've made a lot of investments in PQC.

2218.267 -> Again, the nutshell version, which I'm sure most of you know

2220.9 -> is nobody has a sufficiently coherent quantum computer today

2225.267 -> to crack asymmetric cryptography.

2227.633 -> But all the experts say that if we can invent one,

2231.267 -> and we don't usually like to bet against engineering teams,

2233.5 -> once problems go from theory to engineering,

2236.133 -> the engineers are often very good at succeeding at very hard problems.

2239.333 -> And so it's not unlikely that in the future, not too distant future,

2243.433 -> there will be a sufficiently powerful quantum computer

2246.533 -> that could crack today's asymmetric cryptography.

2249.167 -> Now, the good news is often not mentioned,

2251 -> which is symmetric cryptography

2253.167 -> does not suffer much from quantum computers.

2256.1 -> So if you're using AS256 for encrypting something

2259.5 -> that you write to disk as EBS and S3 and Dynamo

2262.567 -> and all our storage services do,

2264.8 -> quantum computers would speed up brute forcing of that,

2268.733 -> cracking that crypto by a factor of 100, 1,000, doesn't matter.

2273.9 -> So much power is required to crack those that

2277.867 -> that's essentially irrelevant,

2279.633 -> at least as far as we know, according to today's experts.

2282.5 -> But asymmetric cryptography, totally different.

2285.133 -> It's much, much--very susceptible to being cracked

2287.967 -> by a quantum computer using brute force techniques.

2291.067 -> And therefore, we have to get ahead of this problem

2293.167 -> before it becomes a problem.

2294.7 -> So we've made a lot of investments in post-quantum cryptography.

2297.067 -> We have production systems today in production

2299.6 -> using hybrid key exchange,

2300.933 -> which means that it encrypts the inner keys of a TLS session

2305.433 -> with both elliptic curve and post-quantum

2309.767 -> so that if one is cracked or the other,

2312.133 -> you still have basically defense in depth.

2314.967 -> So a lot of really interesting technology going on there.

2317.167 -> But again, the key thing is we're doing this in the open,

2319.267 -> so that anyone can benefit from all the investments

2321.3 -> and the work that we're doing in this space.

2325.567 -> Speaking of formal verification,

2328.233 -> and because that's one of the key sub themes of this open source release,

2333.333 -> which we just made a month or so ago,

2335.667 -> we've introduced to the world a new--another new language.

2338.767 -> Hey, we need new languages.

2339.967 -> We really felt we did need a new language in this case.

2341.9 -> We looked long and hard at existing authorization languages.

2346.067 -> So this is a kind of a narrow but very important part

2348.833 -> of the security world

2350.467 -> is how do I encode permissions about access to systems?

2356.933 -> If I could step back for those of you who, like me,

2359.067 -> have worked in sort of identity and access management over the years,

2361.767 -> as an industry, we've done a pretty good job on the identity side, right?

2364.9 -> We have a pretty good story about SAML and OIDC

2367.867 -> and blah, blah, blah.

2369.3 -> That allows me to come across into a system with some sort of validated,

2373.667 -> cryptographically validated user with a set of claims.

2376.5 -> Okay, now I show up at a system.

2378.833 -> Now what happens?

2379.967 -> Somebody has to make an authorization decision,

2382 -> like what rights does that person have in the system

2385.3 -> that they're accessing?

2387.3 -> There the industry has done a terrible job of standardization.

2390.667 -> We tried years ago with something called XACML,

2392.933 -> if you know what that is, boy,

2394.233 -> we could go have a cup of coffee and talk about that.

2397.533 -> Failed miserably.

2398.867 -> And if you think about today's IT systems, on premises especially,

2403.5 -> you have these ACL models everywhere

2405.6 -> SharePoint ACLs, Exchange, different file systems,

2408.167 -> everything has an access control model

2410.767 -> that's all completely disjoint, completely heterogeneous,

2414.933 -> and it's not a good story in terms of wanting to understand

2419.1 -> and answer those basic questions.

2420.433 -> Who has access to what?

2421.667 -> Like that is the holy grail of access management systems?

2424.733 -> Who has access to what?

2426.067 -> Today, super hard to answer that question.

2428.1 -> It's easier in the cloud, by the way,

2429.533 -> because you have a common identity management system for all the APIs.

2433.233 -> Still not super easy to answer, and we're getting there,

2435.1 -> but at least there's a possibility,

2436.433 -> because of the unification on the access side.

2439.933 -> But long digression, but we decided that our existing

2444.733 -> IAM system works great, but was it the right language

2447.933 -> to expose for a broader set of use cases?

2450.067 -> We decided not.

2451.133 -> I can go into lots of great details why not.

2453.2 -> We looked at existing open source or standards technologies.

2456 -> They didn't really meet the requirements,

2458.067 -> so we invented a new one called Cedar.

2461.167 -> And one of the many great things about Cedar, which I won't go into,

2464 -> but one of the most interesting things is it was

2465.833 -> built by a joint engineering team

2468.2 -> that included both experts in access management,

2470.8 -> but also formal verification scientists

2473.533 -> who built both the language for formal verification

2477.867 -> as well as the implementation, the runtime and the libraries.

2481.233 -> Those are also formally verified,

2482.967 -> because you really want correctness when it comes to access decisions.

2486 -> So this is a really cool technology,

2487.567 -> and there's some great blogs on Cedar,

2489.667 -> if you want to dig into the gory details.

2492 -> It includes another technology called differential testing,

2494.233 -> which is a very interesting sort of probabilistic fuzzing,

2498.933 -> if you will, because even with formal verification,

2501.933 -> you still want to do some testing

2503.567 -> to make sure that your tools are all working properly.

2505.367 -> So enough on Cedar, but it's a very exciting release,

2508.1 -> and we hope the world adopts this and uses it everywhere

2510.733 -> because even though there'll still be some challenges

2513.367 -> in terms of unification,

2514.933 -> having a common access language would be a huge win,

2517.2 -> and we're working hard to make that true.

2519.833 -> Yeah. You know, Mark, I was one of the naysayers

2522.567 -> who said that there was no need for Cedar,

2524.233 -> because we have other access languages out there.

2527.133 -> And when this project came up internally,

2529.867 -> I was one of the folks who said, “Why are we reinventing the wheel?

2533.3 -> This doesn't make sense.”

2534.9 -> But the formal verification of both the engine,

2538.433 -> the access engine, and the policy itself really sold me

2542.6 -> that this was something new that actually needed to exist.

2545.967 -> I'm excited about Cedar.

2548.7 -> I'm excited about the attention that it's getting as well,

2551.267 -> because people seem genuinely excited about this,

2554.833 -> and those people are not even AWS customers.

2557.433 -> They're recognizing that this is a gap

2559.833 -> that we have in the security space.

2563.733 -> So I want to talk a little bit about Snapchange,

2567.167 -> which was another open source release we made last month.

2571.733 -> And Snapchange came out of a team inside AWS

2574.967 -> called Find and Fix or our F2 team.

2578.2 -> And to explain a little bit about what F2 does,

2582.267 -> the F2 team has a mandate that they are to go look at what AWS

2588.333 -> and our customers are using the most

2591.267 -> and then to audit it to find problems,

2593.633 -> specifically security problems in the most commonly used

2597.767 -> open source tools that AWS and our customers make use of.

2603.367 -> And they've been on this journey for roughly a year now.

2608.367 -> They've built up a team of security researchers,

2611.367 -> and they're trying to figure out how to scale up their capacity

2615.633 -> to find problems, and Snapchange is a fuzzing tool,

2620.467 -> and fuzzing essentially tosses a bunch of strange

2624.7 -> inputs into various break points in a piece of software.

2629.567 -> And frankly, fuzzing as a general tool

2633.933 -> has been responsible for finding lots of problems.

2637.933 -> And they looked around,

2639.6 -> they're using plenty of fuzzing tools as it is today.

2643 -> But when they looked, they said there are some things that we can improve.

2647.067 -> Specifically, Snapchange is a tool that works in an emulator

2653.067 -> or a hypervisor environment.

2654.4 -> It presumes that the software is actually going to be

2656.867 -> running as a virtual machine,

2660.4 -> and it is able to inject the fuzzing via that layer.

2667.067 -> And so I said, “Why are you doing this?

2672.1 -> There are already tools that do this.”

2673.433 -> And one of the call outs was, well, those tools today

2676.433 -> require a modified KVM and/or a modified kernel.

2681.667 -> So you've got to load a specific kernel module

2683.6 -> that does not ship in tree.

2685.933 -> And that's a barrier to some folks

2689.167 -> for being able to easily deploy this, being able to run it at scale.

2695.7 -> The other thing that they wanted to do

2696.967 -> is they wanted to scale this across multiple cores and so multiple

2702.2 -> CPUs at a single time and run that allowing folks to hopefully scale up

2708.733 -> and make their fuzzing activities a little faster.

2714.267 -> So Snapchange allows folks to basically use breakpoints in code

2720.1 -> and submit all of this fuzzing data into the program

2726.067 -> and to replay that, and so dramatically more scalable

2732.067 -> and hopefully faster for folks to use.

2734.833 -> This is really targeted at the security researcher audience.

2737.567 -> This is not something that we would expect an average developer

2740.3 -> to go make use of.

2741.867 -> We're excited about it, because the security community

2744.067 -> seems to be finding this useful.

2746.2 -> And I'm really excited that this team

2748.967 -> is getting a little bit of visibility,

2751.7 -> because they're doing amazing things in terms of finding bugs,

2755.7 -> because their mandate is both to find and to fix.

2760.433 -> They're not just looking at bugs that they're finding in code

2764.633 -> and saying, “Hey, here's a security vulnerability.”

2767.7 -> They're developing proof of concept.

2770 -> They're developing a patch and shipping

2771.667 -> that to minimize the workload on the open source maintainer,

2775.9 -> because we don't want to stand up a team

2778.467 -> that basically creates a denial of service,

2782.633 -> a social denial of service attack on open source maintainers.

2785.833 -> So we want to provide them as much help as possible

2788.933 -> when we're going out and looking for security vulnerabilities.

2791.867 -> I'm going to interrupt you for a second.

2793.367 -> Go slightly off script, because I think this is super important.

2795.5 -> It’s something I learned from you when I first started

2797.567 -> getting involved more in open source security.

2799.667 -> So, by the way, David is the president

2801.2 -> of the Apache Foundation in his spare time.

2803.933 -> And very, very long and deep involvement in open source community.

2808.067 -> And I remember when we first started talking about

2809.867 -> these kind of security audits and so forth,

2812.067 -> you sent me this postmortem of a security audit

2814.367 -> that was done on some Apache software.

2816.733 -> And it was so enlightening, because what it made me realize

2819.8 -> is you can go in and you can find bugs.

2821.933 -> There's no problem finding bugs in large software code bases.

2826.267 -> Now what?

2828.267 -> Bugs. Okay, great.

2829.4 -> Now what do I do?

2830.5 -> Where's the resources that are needed to fix the bugs?

2833.133 -> That's a whole different thing.

2834.533 -> And it's also very hard to inject those resources,

2838.033 -> even if they exist, into an existing development team,

2841.2 -> an existing culture, an existing way of building and developing software.

2845.367 -> So I found that super enlightening.

2846.767 -> And it was also kind of an eye opener.

2849.133 -> Like it's not a matter of finding bugs,

2850.733 -> it's a matter of creating this virtuous cycle of finding things,

2854.967 -> but also developing the skills, the capability of the community

2858.967 -> that owns the software, prioritizing those fixes.

2861.1 -> All those things are a much harder problem than just finding things.

2864.467 -> And I think that's a super important story around how we need to,

2867.967 -> as a community, get better at doing this stuff.

2870.433 -> I think that report that you mentioned was talking

2873.4 -> about all of the influx of help that happened after Heartbleed,

2877.867 -> and I use "help" in air quotes, right?

2880.2 -> Because security is not a one-time thing that you can say,

2883.567 -> all right, we're secure today and then walk away.

2887.067 -> It requires that continuous investment

2890.667 -> where you're making long term investments

2893.667 -> in not just technology but in communities

2896.4 -> and making sure that you can actually shift the culture,

2902.267 -> shift the practice to something more secure.

2905.067 -> It's not--you're right, it's not about finding bugs.

2907.9 -> If it was that easy, we would—

2910.367 -> We'd be much better today.

2911.5 -> We would probably not be giving a talk today on open source security.

2916.067 -> So.

2919.367 -> I said this earlier, but open source projects

2922.667 -> do not work on code contributions alone.

2925.6 -> And we think that AWS, you can see it in our leadership principles,

2932.367 -> size and scale bring great responsibility,

2934.767 -> and we certainly have a responsibility to open source.

2939.267 -> And so we recognize that.

2941.533 -> And one of the mechanisms that we can make use of

2945.067 -> is to support a number of open source projects and open source foundations.

2951.967 -> And we do this across a number of places.

2955.133 -> So we support places like the Python Software Foundation,

2958.467 -> the Apache Software Foundation.

2960.7 -> We're members of the Linux Foundation and Cloud

2962.4 -> Native Computing Foundation

2964.167 -> and provide a baseline of support via that mechanism.

2969.367 -> That provides us a way to make sure

2971.467 -> that that base level human infrastructure is in place

2976.1 -> and that people are able to get things done.

2979.167 -> But I want to dive into how we're thinking

2981.667 -> about funding security responsibilities,

2985.133 -> because I think that is a separate layer above

2987.9 -> just funding the open source projects themselves.

2991.6 -> So the Python package index, if you're not familiar with PyPI,

2997.6 -> it is a—

2999.567 -> You're not a Python developer if you're not familiar with it.

3001.667 -> You aren't. You aren’t.

3003.1 -> You know, this is how the world consumes Python, right?

3006.967 -> It is the package repository.

3008.9 -> If you're a Java developer, there's Maven Central.

3011.267 -> If you're a Python developer, there's the Python package index,

3015.567 -> and it is a huge attack surface for folks

3019.3 -> trying to impact the software security supply chain.

3023.167 -> And we recognized this early on, paid attention to it,

3026.5 -> started working with the Python Software Foundation

3029.3 -> and said what can we do together to improve this?

3032.567 -> And they said, “Well, you know, today we're doing mainly reactive

3035.667 -> response to security issues.

3038.367 -> We don't really have a great security strategy

3041 -> for the package repository itself.

3044.067 -> We're not proactively going out and looking for threats.

3047.467 -> We would like to change that.”

3049.333 -> They put together a proposal and brought that to Mark and I

3051.867 -> and said, “Hey, this is what we'd like to do.

3053.933 -> Can you fund this?” And we said, “Absolutely.

3056.2 -> This makes perfect sense.

3057.4 -> We'd love to jump in here,”

3059.233 -> because we consume packages out of the Python package index.

3065.6 -> All of our developers who are doing Python do that.

3068.3 -> Our customers do as well.

3070.767 -> And so does the rest of the world.

3072.733 -> You're not developing in Python if you're not using this.

3076.633 -> And so we have been working with them

3078.7 -> to help create proactive strategies, build up some internal staffing,

3084.6 -> so that they can actually respond to issues timely.

3088.3 -> And we're not depending upon volunteers in Nebraska

3094 -> to respond to a security issue in the Python package.

3097.333 -> We just have some individual in mind when you refer to,

3099.4 -> so we won't mention any names.

3101.233 -> We won't mention a comic's name, but we're not responsible.

3106.4 -> We're not responsible if we're not taking into account

3110.933 -> these distribution points

3112.267 -> and making sure that we are helping to fund their security,

3116.7 -> because that impacts all of us.

3119.733 -> We have that shared destiny we talked about earlier.

3124.467 -> We've also--and we've hinted around at this a little bit earlier,

3128.567 -> but there's a number of scholarly articles

3131.567 -> written by people far smarter than I

3133.9 -> that are looking at the overall timeline of security vulnerabilities.

3138.333 -> And they're reporting that 65% of security vulnerabilities

3143.7 -> in the past decade are memory related.

3148.467 -> Two thirds of security vulnerabilities

3152.3 -> are from a single class of security threat.

3157.5 -> And one of the reasons we are so interested in Rust

3160.067 -> is that it provides tooling to ensure memory safety.

3164.167 -> That's not a panacea for--Rust does not make you magically secure.

3169.067 -> And I don't want to paint that picture,

3171.133 -> but it is a much more assured position

3175.567 -> from a memory safety perspective,

3177.533 -> and I'm excited about that for what we're developing internally, Mark.

3182.3 -> But we looked at where some of the entry points

3186.8 -> in terms of open source was.

3188.933 -> And I remember us sitting in your office in Virginia a year ago now

3194.367 -> almost and talking about the places where we were seeing attacks

3199.967 -> and seeing security vulnerabilities in open source.

3203.167 -> And, again, security is not a point in time thing that you can go say,

3208.733 -> “I'm secure today and I don't have to worry about it anymore.”

3211.7 -> And so we looked at where can we focus on things

3215.833 -> that are on a network boundary,

3217.733 -> things that are getting lots of direct Internet traffic

3220.1 -> or they're parsing huge files.

3223.267 -> How do we go address that?

3225.467 -> And so we identified four initial projects

3229.133 -> and asked the Prossimo project out of the Internet Security Research

3233.5 -> group to go rewrite those for us.

3236.033 -> And we provided funding to rewrite those.

3238.567 -> So those initial four are the NTP daemon.

3242.467 -> We asked for a Rust implementation of that, sudo and su,

3246.767 -> because again, increasing your authorization level

3251.1 -> is something that you really don't want to have memory issues in.

3255.367 -> Rustls—

3256.5 -> There's a long and sad history of bugs in that.

3259.367 -> There are, a lot of memory bugs specifically in sudo.

3263.667 -> Rustls, the TLS library for the Rust programming language,

3269 -> we wanted to improve how fast Rustls

3272.267 -> was going to be able to be production ready.

3275.567 -> We want to make sure that--Rustls is already

3277.833 -> Rust written, so no inherent rewriting,

3281.933 -> but we want to mature that rapidly,

3284.4 -> because we think that a TLS implementation

3287.433 -> that's memory safe is super important.

3290.367 -> If your encryption fails, you've got lots of other problems,

3293.633 -> and then an AV1 decoder,

3296 -> and AV1 is itself an open source success story.

3299.667 -> And we wanted to make sure that that this decoder

3304.867 -> that's processing lots of huge files, both audio, video and images

3310.767 -> is written well and is secure.

3315.467 -> So we've been doing--we've been investing in a lot of that.

3320.267 -> And finally, the industry as a whole has coalesced

3324.967 -> around the Open Source Security Foundation.

3327.7 -> And Mark championed joining OpenSSF years ago,

3334.167 -> right after it came out.

3337.1 -> We joined that.

3338.333 -> We started investing and spending time there.

3342.3 -> Folks from Mark’s office were certainly heavily

3345.233 -> invested in trying to advance the state of security in open source.

3351.033 -> But we recognized that there was opportunity to do more.

3354.367 -> And so last year we committed $10 million towards OpenSSF

3360.267 -> to make investments in long term sustainable,

3364 -> open source security initiatives.

3365.967 -> And we did a couple of those.

3367.233 -> I'll talk about them real quickly, Alpha Omega,

3369.733 -> which has two objectives.

3371.567 -> The first is paying attention to the 10,000

3374.8 -> most widely used open source components

3377.7 -> and creating automation

3381.367 -> around finding security vulnerabilities and patching it.

3384.2 -> So they're really heavily focused on automating security

3388 -> as much as possible.

3389.767 -> The other side of Alpha Omega is focused on the top 100.

3393.6 -> What can we do that has outsized impact

3396.5 -> across the most heavily consumed open source packages?

3400.033 -> And how do we make that security investment sustainable?

3403.9 -> They're doing great work.

3405.033 -> We're seeing lots of things happening there

3409.167 -> in a number of different communities

3411.333 -> where we continue to be excited about that.

3414.133 -> Security scorecards, though, Mark talked about consumption, right?

3418.8 -> And we at AWS, we delegate open source

3422.833 -> consumption decisions to builders.

3426.467 -> Nobody comes to Mark asking for permission

3428.267 -> to use another programming language,

3430 -> even though he's in the security organization.

3433 -> Nobody comes to me in the open source organization saying,

3435.7 -> “I want to use this thing.

3436.867 -> Is it okay?”

3438.6 -> An individual developer is doing that.

3440.4 -> And we think security scorecards, which will provide an automated

3443.6 -> look at a number of health metrics and security metrics,

3448.333 -> provides much greater information to base decisions upon,

3453.867 -> so that those developers who are deciding

3455.933 -> what open source they're consuming can make better informed decisions.

3460.167 -> We're excited about some of the work coming out of security scorecards

3463.367 -> and look forward to that being more ubiquitous.

3466.9 -> And of course, we're doing a lot of general support as well.

3473.367 -> So let's close out our session.

3476.3 -> And just as a reminder of our takeaways and our pillars,

3479.633 -> work upstream and contribute to the open source world

3482.867 -> and provide financial support.

3484.433 -> And for all of these things, we encourage you,

3486.933 -> the broader community, to join with us in these areas.

3489.767 -> Think about ways in which your organization

3491.333 -> can work in one or two or three of these ways,

3494.167 -> or come up with new ways to work to support open source.

3498.167 -> Join with us.

3499.233 -> Come to us with ideas.

3500.433 -> We're very interested if you have funding ideas,

3502.933 -> if you have engineering ideas that you think can help in this world,

3506.867 -> that's super, super important.

3508.933 -> We're going to join together to make the world a safer place,

3511.467 -> because we all depend on secure open source.

3513.933 -> And we thank you very much for coming

3515.533 -> and have a great rest of your time here at re:Inforce.

3519.267 -> -Thank you. -Thanks.

3520.333 -> [applause]

Source: https://www.youtube.com/watch?v=kMY8gGmWfAI