WEBVTT

1
00:00.000 --> 00:05.060
So this is what it looks like right now. I've got an empty repository with the

2
00:05.060 --> 00:09.720
exception of ReadMe and if I look under Actions, I don't have any actions or

3
00:09.720 --> 00:15.180
workflows that have been defined. But on my local computer, I've made code and

4
00:15.180 --> 00:19.980
I've defined an action. So when I push this up in the GitHub, that's gonna kick

5
00:19.980 --> 00:24.240
off the action and run the bandit test. So I'm gonna go into source control

6
00:24.240 --> 00:24.620
here.

7
00:24.620 --> 00:29.340
I'm going to queue up all of these changes and we're gonna make this commit.

8
00:29.340 --> 00:36.760
And we're gonna say push our first test to GitHub. I'll say commit. We're gonna
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:29.340 --> 00:36.760
And we're gonna say push our first test to GitHub. I'll say commit. We're gonna

9
00:36.760 --> 00:43.040
sign it with my SSH keys and then this sync will push that up into GitHub. So

10
00:43.040 --> 00:48.180
now when I jump back into GitHub and refresh, we see now I've got the

11
00:48.180 --> 00:54.380
workflows and the code and actions should now be running. Sure enough, the

12
00:54.380 --> 00:58.680
orange right here indicates that it's currently running. If I give it a click,

13
00:58.680 --> 01:03.700
we see that it's now working through the process and boom, it was able to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

13
00:58.680 --> 01:03.700
we see that it's now working through the process and boom, it was able to

14
01:03.700 --> 01:08.820
successfully complete this. When I jump into Bandit scan, we're gonna take a

15
01:08.820 --> 01:15.540
look at what it did. Let's look under run Bandit and interestingly, it detected

16
01:15.540 --> 01:21.540
this as a low severity item with medium confidence. And that's largely because

17
01:21.540 --> 01:26.140
of how Bandit is constructed to think of things as like hard-coded passwords

18
01:26.140 --> 01:29.980
as low severity. And you're thinking to yourself, well that sounds pretty bad,

19
01:29.980 --> 01:30.240
but
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

19
01:29.980 --> 01:30.240
but

20
01:30.240 --> 01:35.840
what it really thinks is more severe is any action that allows the user to

21
01:35.840 --> 01:41.520
potentially take over the computer itself. So when I jump back to cursor and to

22
01:41.520 --> 01:41.620
my

23
01:41.620 --> 01:48.680
application, I may paste in something like evaluate user input, allowing users

24
01:48.680 --> 01:54.240
to type their own commands for the operating system directly in to your

25
01:54.240 --> 01:58.780
front end application. So just by creating this function that will take user

26
01:58.780 --> 02:05.460
input and use eval, that's going to return this as a high severity flag item.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
01:58.780 --> 02:05.460
input and use eval, that's going to return this as a high severity flag item.

27
02:05.460 --> 02:12.420
So I'm going to go ahead and make this change, we'll go ahead and say add high

28
02:12.420 --> 02:19.580
risk operation, we'll commit that change and push it. And this will kick off a

29
02:19.580 --> 02:25.640
new GitHub action run. Now we've added high risk operation and it's going to be

30
02:25.640 --> 02:29.440
running in the background. So we'll let it run. This will only take a few

31
02:29.440 --> 02:29.940
seconds

32
02:29.940 --> 02:33.960
because it's installing the pip environment. And then when it's done, we'll
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

32
02:29.940 --> 02:33.960
because it's installing the pip environment. And then when it's done, we'll

33
02:33.960 --> 02:38.480
see, oh look, now we've got a failure. And this is exactly what we were hoping

34
02:38.480 --> 02:38.600
to

35
02:38.600 --> 02:44.960
see. Now that we have a medium risk operation with high confidence problem,

36
02:44.960 --> 02:51.480
this is going to fail the entire pipeline. So at no point is the pipeline

37
02:51.480 --> 02:52.100
allowed

38
02:52.100 --> 02:57.780
to progress to building artifacts, shipping code and delivering it to end

39
02:57.780 --> 03:02.680
infrastructure, nor is it attempting to deploy new resources in the cloud
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

39
02:57.780 --> 03:02.680
infrastructure, nor is it attempting to deploy new resources in the cloud

40
03:02.680 --> 03:03.060
either.

41
03:03.060 --> 03:09.380
This is why dev sec ops exists. This was not a heavy lift, was it? To integrate

42
03:09.380 --> 03:13.900
something like bandit, if I jump back here, to integrate something like bandit

43
03:13.900 --> 03:19.640
for Python applications was really just telling it install bandit and run a

44
03:19.640 --> 03:26.060
bandit scan. These four lines of code is all it took to start scanning for

45
03:26.060 --> 03:31.900
severe issues with Python applications. It's similar for other programming
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
03:26.060 --> 03:31.900
severe issues with Python applications. It's similar for other programming

46
03:31.900 --> 03:36.720
languages like JavaScript. They also have their own security frameworks built

47
03:36.720 --> 03:43.520
into it. There are dozens of different ways to integrate security into a DevOps

48
03:43.520 --> 03:47.980
pipeline. And this is one of the easiest examples to wrap your head around. At

49
03:47.980 --> 03:52.940
this point, you're probably able to describe exactly what a dev sec ops

50
03:52.940 --> 03:58.580
pipeline is, because we covered what a DevOps pipeline is and what CI CD is.

51
03:58.580 --> 04:04.860
Then we saw how security can be integrated into it and how a good measure
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

51
03:58.580 --> 04:04.860
Then we saw how security can be integrated into it and how a good measure

52
04:04.860 --> 04:10.640
of security can actually fail pipelines before we start delivering vulnerable

53
04:10.640 --> 04:14.580
code to our production systems. I hope this has been informative for you and I

54
04:14.580 --> 04:17.860
like to thank you for viewing.
