diff --git a/docs/src/app/concepts/ConceptsTab.jsx b/docs/src/app/concepts/ConceptsTab.jsx index 61dbf7a..d8d742b 100644 --- a/docs/src/app/concepts/ConceptsTab.jsx +++ b/docs/src/app/concepts/ConceptsTab.jsx @@ -50,7 +50,7 @@ turing-validating-security-definitions-during-development-process'}

An SDV pipeline does all the same tasks as any existing CI/CD pipeline, however, if an application code change request results in a change to the security definitions - required for that application to run an + required for that application to run, an approval process is initiated, which  must be approved by a Security Admin diff --git a/docs/src/app/how/approval-bot/ApprovalBotStep.jsx b/docs/src/app/how/approval-bot/ApprovalBotStep.jsx index a587670..044be67 100644 --- a/docs/src/app/how/approval-bot/ApprovalBotStep.jsx +++ b/docs/src/app/how/approval-bot/ApprovalBotStep.jsx @@ -29,7 +29,7 @@ export default function ApprovalBotStep({ of the SDV workflow.

- At this point, there are two open changes requests, one for the app or test code, and one for the + At this point, there are two open change requests, one for the app or test code, and one for the security baseline, and from the perspective of the SCM tool there is no direct relation between them. Additionally, SCM tools currently do not provide the ability for actions in a change request to directly affect the status of another change request in a completely different repository. diff --git a/docs/src/app/how/ci-pipeline/ciPipelineStep.jsx b/docs/src/app/how/ci-pipeline/ciPipelineStep.jsx index 60ebc06..a5a3f83 100644 --- a/docs/src/app/how/ci-pipeline/ciPipelineStep.jsx +++ b/docs/src/app/how/ci-pipeline/ciPipelineStep.jsx @@ -2371,7 +2371,7 @@ wk '{gsub(/\\./,"-"); print}'\`

  • - If running in an Galasa Ecosystem, build a list of tests to run by  + If running in a Galasa Ecosystem, build a list of tests to run by 
    - This option works well if there is a small number of tests with no requirement to run test in parallel. + This option works well if there are a small number of tests with no requirement to run test in parallel.

    Ecosystem using DSE

    diff --git a/docs/src/app/how/zos-configuration/ZosConfigStep.jsx b/docs/src/app/how/zos-configuration/ZosConfigStep.jsx index 25405e5..e848d64 100644 --- a/docs/src/app/how/zos-configuration/ZosConfigStep.jsx +++ b/docs/src/app/how/zos-configuration/ZosConfigStep.jsx @@ -78,8 +78,8 @@ export default function ZosConfigurationStep({ as this will increase the number of tests that can be ran in parallel.
    This is because a user must only be used for one test at a time, to eliminate the risk of capturing - "Security noise", which would be the capturing of security being used by another test using - the same user at the same time. + "Security noise", which would be the capturing of security requests from another test + using the same user at the same time.
    The number of users in the pool should be relative to the amount of tests using the role.

    diff --git a/docs/src/app/problem/ProblemTab.jsx b/docs/src/app/problem/ProblemTab.jsx index b3f6c83..6b5dfb0 100644 --- a/docs/src/app/problem/ProblemTab.jsx +++ b/docs/src/app/problem/ProblemTab.jsx @@ -36,7 +36,7 @@ export default function ProblemTab({ SDV automates and improves the efficiency of identifying required changes to security when changes are made to CICS applications. This is currently a slow, error prone, and manual process, often leading to - application breakages when the application is first ran in an environment with security switched on, which + application breakages when the application is first run in an environment with security switched on, which is more common than not, pre-production!