WEBVTT

1
00:00:00.628 --> 00:00:10.908
Welcome to NxSAM training. This module covers Container Security, and it has one idea at its centre that makes everything else follow.

2
00:00:11.178 --> 00:00:21.340
An image is immutable. You do not patch a running container the way you patch a server - you build a new image and replace what is running with it.

3
00:00:21.939 --> 00:00:38.076
That changes what remediation means. Elsewhere, fixing a finding means changing the thing that has it. Here it means producing a different thing - so a tag change is a different asset, not an update to an existing one.

4
00:00:38.650 --> 00:00:46.436
Collections are how the estate is organised, and the list has one column that tells you whether a collection is still real.

5
00:00:47.016 --> 00:01:00.176
Collection Name and Description are yours. Status says whether it is active. Owner says who is accountable for it. And Active Image Count is the one to read.

6
00:01:00.791 --> 00:01:16.647
A collection defined months ago with no active images is describing something that is no longer deployed. It is not an error, but it is a collection whose findings will never change, and it quietly inflates any count that includes it.

7
00:01:17.253 --> 00:01:20.987
Scans arrive through audits and produce images.

8
00:01:21.576 --> 00:01:38.749
An image is identified by three things together: its registry, its repository and its tag. All three are needed - the same repository name in two registries is two different images, and two tags of the same repository are two different images too.

9
00:01:39.326 --> 00:01:50.232
The image list carries that identity, then a Vulnerability figure and a Compliance figure side by side, then Last Scan Date, its Collections, and its Status.

10
00:01:50.806 --> 00:02:06.271
Last Scan Date is the column people skip and should not. An image with a low vulnerability count and a scan date from four months ago is not a clean image - it is an unmeasured one, and the two look identical in every summary.

11
00:02:06.852 --> 00:02:19.755
Each image row offers View Vulnerabilities and View Compliance to open its findings, and Export Vulnerabilities and Export Compliance to take them out - kept separate for the same reason the counts are.

12
00:02:20.323 --> 00:02:27.893
Because a container image produces two genuinely different kinds of finding, and they are never mixed into one number.

13
00:02:28.513 --> 00:02:43.308
Vulnerabilities are known weaknesses in the packages an image contains. Registry and repository identify the image. C V E identifies the weakness. Severity ranks it.

14
00:02:43.892 --> 00:02:56.768
Package Info names the package and its version, and that is what makes the finding actionable. The fix is always to move that package - you cannot configure around a vulnerable library.

15
00:02:57.395 --> 00:03:18.594
Fix Info is the one column that says whether the problem is solvable yet. It reports whether an upstream fix exists - affected, end of life, under investigation, or fixed in a named version. A finding whose package is end of life cannot be patched at all; that one has to be replaced.

16
00:03:19.195 --> 00:03:30.534
The row of severities above the table is not a key - each one is a filter. On an image with two hundred findings this is how the list becomes a morning's work.

17
00:03:31.148 --> 00:03:46.852
Read Package Info and Severity together and you can sort real work from noise in a single pass: a critical in a package you can move is this sprint's work, and a critical in a base image you do not control is a conversation with whoever owns it.

18
00:03:47.447 --> 00:04:03.224
Where a finding sits in its life - the collection it belongs to, its status, and whether it has passed its S L A date - is not on this per-image view. Those three columns live on the search screen, which we will open shortly.

19
00:04:03.832 --> 00:04:10.682
Compliance findings are the other kind, and two of their columns exist for something genuinely important.

20
00:04:11.281 --> 00:04:22.595
These are configuration and content checks against the image itself. Compliance Details names the check, with its severity and the collection it was found in.

21
00:04:23.177 --> 00:04:38.740
Then Secret Path and Secret Location In File. Those exist because one of the most valuable things a container scan finds is a credential baked into the image - a key, a token, a password committed into a layer.

22
00:04:39.328 --> 00:04:49.633
The path tells you which file, and the location tells you where inside it. Together they are what makes the finding fixable rather than merely alarming.

23
00:04:50.223 --> 00:05:06.074
Treat one of those as an incident rather than a finding. An image is distributed wholesale, so a secret inside one has been copied everywhere that image has ever run - and rotating the credential matters more than rebuilding the image.

24
00:05:06.676 --> 00:05:22.688
Notice the two kinds sitting in one list. A benchmark failure is a setting somebody chose. A secret is a file somebody committed. They are found by the same scan and they are fixed by completely different people.

25
00:05:23.306 --> 00:05:39.586
The title opens the finding itself - what was found, why it matters, and what to change. For a secret that last part is never "delete the line": the credential is in the image history, so it has to be rotated as well as removed.

26
00:05:40.182 --> 00:05:46.961
Both kinds of finding have their own search screen, and they answer a question the per-image views cannot.

27
00:05:47.590 --> 00:06:01.971
Not what is wrong with this image, but which images carry this particular problem. A C V E is published on a Tuesday, and the question within the hour is how many of your images contain the affected package.

28
00:06:02.575 --> 00:06:19.530
Because images share base layers, one vulnerable base can put the same finding into dozens of applications - and fixing the base fixes all of them at once. The search screens are how you see that shape instead of treating each image separately.

29
00:06:20.122 --> 00:06:37.461
More Filters is where the questions get sharper: how old a finding is, whether it is inside its remediation window, and whether that window has already closed. Age and S L A together are what separate a backlog from a breach of your own policy.

30
00:06:38.058 --> 00:06:47.164
And the row will tell you exactly that, if you ask it. The action on the right lists every image carrying this package.

31
00:06:47.797 --> 00:07:03.549
Three images, one package, three different totals. The bar beside each count is that image's severity mix - so you can see at a glance which one to rebuild first, and it is not always the one with the most findings.

32
00:07:04.142 --> 00:07:20.329
The legend is worth reading once. This module ranks findings on seven levels rather than the usual four, because the distributions it ingests grade their own advisories - and a Moderate from one vendor is not a Medium from another.

33
00:07:20.955 --> 00:07:31.670
The compliance search does the same for configuration findings and secrets, which is exactly how you answer whether one leaked credential reached more than one image.

34
00:07:32.260 --> 00:07:38.655
Both findings screens offer two exports, and picking the wrong one misleads whoever reads it.

35
00:07:39.269 --> 00:07:50.418
Export Overall lists every occurrence - the same C V E in forty images is forty rows. Export Unique lists each distinct finding once.

36
00:07:51.016 --> 00:08:08.546
Overall answers how much work there is. Unique answers how many distinct problems there are. On a container estate those two numbers differ enormously, and quoting the wrong one makes a remediation plan either terrifying or complacent.

37
00:08:09.151 --> 00:08:16.770
The rule of thumb: use unique when deciding what to fix, and overall when estimating how long it will take.

38
00:08:17.392 --> 00:08:38.162
That is Container Security. Images identified by registry, repository and tag. Collections to group them. Vulnerabilities and compliance kept apart because they are different problems with different fixes. And search screens that answer which images share a finding.

39
00:08:38.799 --> 00:08:54.119
Two columns repay attention more than the rest: Last Scan Date, because an unscanned image and a clean one look identical in every total; and Secret Path, because a credential in a layer is an incident and not a backlog item.