WEBVTT

1
00:00:00.602 --> 00:00:13.090
Welcome to NxSAM training. This module covers Application Security: weaknesses in the software your organisation builds or runs, and how to read every screen in it.

2
00:00:13.362 --> 00:00:28.883
Findings arrive from code scanners, dynamic scanners, composition analysis, secrets scanning and manual testing. They are tracked together against the application they affect rather than kept in separate piles per tool.

3
00:00:29.483 --> 00:00:54.270
Static analysis reads source code and finds flaws before the application runs. Dynamic analysis tests the running application from outside. Composition analysis examines third-party libraries. Secrets scanning finds credentials committed into source control. And manual testing finds logic flaws the tools cannot.

4
00:00:54.868 --> 00:01:05.678
The same application usually carries findings from several at once, and that is the design rather than duplication. They see genuinely different things.

5
00:01:06.259 --> 00:01:18.366
One distinction underpins every screen: an application is the thing you are protecting, and an audit is one assessment of it. Applications persist; audits accumulate.

6
00:01:18.973 --> 00:01:27.479
The columns are grouped rather than flat, which makes the list denser than it looks. We will take them one at a time.

7
00:01:28.068 --> 00:01:44.566
Request Info carries who asked for the audit and when it starts. Read it when you are trying to work out why an assessment exists - a request raised by a project team and one raised by a compliance deadline usually need different conversations.

8
00:01:45.186 --> 00:02:01.468
Audit Details carries the application, its asset type and the audit's own name. The asset type matters here: the same application name can exist as a web application and as a mobile one, and they are separate assets with separate findings.

9
00:02:02.070 --> 00:02:15.811
Vulnerabilities is the count found so far. Treat it as progress rather than as a result - a low count early in an assessment means the work has not finished, not that the application is clean.

10
00:02:16.419 --> 00:02:27.736
Audit Properties holds the configurable fields your organisation has defined on audits. Those are yours, so what appears there differs between deployments.

11
00:02:28.337 --> 00:02:39.603
And Audit Status is where the assessment has reached. This is the column that decides whether the findings inside are visible anywhere else, and we will come back to why.

12
00:02:40.219 --> 00:02:46.805
The row menu divides into three jobs, and what it offers depends on where the audit has reached.

13
00:02:47.404 --> 00:03:01.695
Running the audit. Manage Audit Scope defines what is in and out. Manage Test Summary records the testing narrative - what was tested and how, which is what a client or an auditor asks for.

14
00:03:02.281 --> 00:03:16.739
And Re-Audit starts a fresh assessment of the same application while leaving the previous one intact. Use it rather than reopening an old audit, because comparing this quarter to last quarter needs both to exist.

15
00:03:17.330 --> 00:03:27.802
Reading it. View Vulnerabilities opens the findings for this audit alone, which is the shortest route from a list of assessments to the work itself.

16
00:03:28.420 --> 00:03:37.599
View Status History shows how the audit moved through its states and who moved it - which is the audit trail somebody will eventually ask for.

17
00:03:38.178 --> 00:03:46.380
And View Audit Chain shows this audit's relationship to the ones before it, so a re-audit can be traced back to its original.

18
00:03:46.968 --> 00:03:57.826
And changing it. Delete Audit removes the assessment; Edit Audit Details appears while the audit is still open, which this completed one is not.

19
00:03:58.407 --> 00:04:03.600
Now the rule that generates more questions than the rest of the module together.

20
00:04:04.221 --> 00:04:15.636
Findings are reviewed and approved into the audit. Until that happens they are visible inside the audit and absent from every posture and report count outside it.

21
00:04:16.238 --> 00:04:28.757
So an auditor can be looking at findings while the counts everywhere else show nothing, and neither is broken. The product is declining to report a result nobody has stood behind yet.

22
00:04:29.354 --> 00:04:40.307
If a colleague says a count or a report is missing findings they can plainly see, check approval status before anything else. It is very nearly always this.

23
00:04:40.910 --> 00:04:54.120
Once approved, findings get an S L A by severity and become visible to the application owner. The owner fixes, a retest confirms, and the finding is validated and closed.

24
00:04:54.758 --> 00:05:01.103
The findings screen is where most of the working time goes, so every column is worth knowing.

25
00:05:01.717 --> 00:05:16.177
Vulnerability carries the title, the affected U R L and a tracking identifier. The identifier is what you quote in a ticket - titles change when a master record is edited, identifiers do not.

26
00:05:16.766 --> 00:05:33.049
Tool says which scanner reported it. Read this before you argue about severity: a static tool reporting an injection flaw and a dynamic tool reporting one are making different claims, because one saw the code path and the other saw the behaviour.

27
00:05:33.651 --> 00:05:49.089
Risk is the severity, mapped from whatever the tool called it onto the platform's five levels. It is a starting point rather than a verdict - tools disagree, and the same weakness can be High in one scanner and Medium in another.

28
00:05:49.711 --> 00:06:03.114
Discovered On is when it first appeared. Read it with the age of the audit: a finding discovered months ago on an audit opened last week arrived from an import of history, not from new work.

29
00:06:03.702 --> 00:06:11.850
Then the pair that gets conflated more than any other in this product. Validation and Current Status.

30
00:06:12.457 --> 00:06:27.084
Validation asks whether the finding is genuine - has somebody confirmed this is real, or is it an unreviewed scanner result. Current Status asks where it has reached in its life - open, fixed, closed.

31
00:06:27.706 --> 00:06:46.148
They move independently. A finding can be validated and still open, which is the normal state of real work. It can be closed without ever being validated, which is worth looking at. And an unvalidated finding still counts, which surprises people.

32
00:06:46.738 --> 00:07:00.431
S L A Details carries the window the severity allows and the date it runs out. Read the two together: the same due date on a critical finding and on a low one are very different amounts of grace.

33
00:07:01.026 --> 00:07:16.588
And Artifacts holds the evidence: screenshots, request and response captures, whatever the tester or tool supplied. A finding with no artifact is harder to defend when somebody disputes it, and disputes are common.

34
00:07:17.171 --> 00:07:24.957
The actions on a finding are not a fixed set either, and here the gate is the finding's own state rather than the audit's.

35
00:07:25.521 --> 00:07:39.139
Editing belongs to the assigned auditor, and only while the finding is still saved or submitted. Once it is approved into the audit, the row stops being editable - which is the point of approving it.

36
00:07:39.725 --> 00:07:56.774
Scoring is carried on the row: the severity, and the C V S S score behind it. Two findings can both be High for different reasons - one trivially exploitable, another severe in impact - and the score is the first place that difference shows.

37
00:07:57.363 --> 00:08:09.548
Tracing. View Status History and Vulnerability History answer who changed this, when, and to what - the question that comes up in every review and every dispute.

38
00:08:10.122 --> 00:08:15.244
Above the table sit the actions that work on the list rather than one row.

39
00:08:15.513 --> 00:08:28.367
Findings can also be entered by hand, and a scanner report can be uploaded, from the audit an auditor is assigned to. That is how manual testing results and anything a tool missed get in.

40
00:08:28.961 --> 00:08:44.217
Change Status and Change Validation move many findings at once. That is what a retest produces - twenty findings confirmed fixed in one pass - and doing it one row at a time is the commonest waste of time in this module.

41
00:08:44.811 --> 00:08:58.363
Compare puts two assessments side by side, and Trend analysis shows the direction of travel across several. Those answer the question every steering meeting asks: is this getting better.

42
00:08:58.983 --> 00:09:06.364
Export Vulnerabilities takes the results out of the product as they stand, which is the other half of that menu.

43
00:09:06.995 --> 00:09:19.485
Config report test plan defines the test plan a report is written against. And More Filters narrows the list - worth checking when a count looks wrong before assuming the data is.

44
00:09:20.090 --> 00:09:27.353
Static scanners in particular report findings that are not genuine, and the platform handles that two ways.

45
00:09:27.921 --> 00:09:40.435
Automatically at import, where the integration carries rules that classify certain findings as false positives on the way in. Or manually, by marking one after review.

46
00:09:41.033 --> 00:09:56.982
Either way the finding is retained rather than deleted, and that matters twice. The decision stays auditable, and the same finding is not re-litigated after every scan - which is what makes a second scan cheaper to triage than the first.

47
00:09:57.588 --> 00:10:06.142
The application inventory is the widest table in the module, and it records what an application is rather than what is wrong with it.

48
00:10:06.737 --> 00:10:18.533
Its columns answer four questions. What is this - the application identifier and type, its production and non-production U R Ls, and its source repository.

49
00:10:19.151 --> 00:10:26.577
What does it handle - data classification, whether personal data is involved, criticality and rating.

50
00:10:27.175 --> 00:10:35.562
Who owns it - business unit and sub-unit, category and sub-category, technical owner and the framework it is built on.

51
00:10:36.184 --> 00:10:45.218
And how exposed is it - usage in users and pages, scope exposure, acceptable downtime, and end-user base size.

52
00:10:45.834 --> 00:11:01.660
Those are not administrative decoration. They are what makes a finding's real-world importance judgeable - a critical finding on an internet-facing application handling personal data is a different matter from the same finding on an internal tool.

53
00:11:02.243 --> 00:11:09.955
Which is why a thinly-populated inventory quietly degrades every prioritisation decision made downstream of it.

54
00:11:10.527 --> 00:11:27.579
That is Application Security in full. Five kinds of source that see different things, applications that persist against audits that accumulate, row menus that change with state, and an inventory that decides how seriously to take any of it.

55
00:11:28.177 --> 00:11:45.733
Three habits carry the module. Check approval status when a count disagrees with the findings you can see. Keep validation and status separate in your head. And use bulk status changes after a retest rather than working one row at a time.