Fix typos

Author: matejak

_posts/2023-04-21-mrac.md

@@ -6,15 +6,15 @@ author: Matěj Týč
 author_url: https://github.com/matejak
 ---
 
-Systems that our contents aims to harden are very often large collections of separate components whose life cycle is independent from the life cycle of the product that ships them.
+Systems that our content aims to harden are very often large collections of separate components whose life cycle is independent from the life cycle of the product that ships them.
 For example, the Red Hat Enterprise Linux consists of more than six thousand of such distinct components, although only a fraction of them s.a. OpenSSH, Grub2 and so on is supported by the ComplianceAsCode project.
 
 Our Red Hat group is contemplating the idea of making the content project better equipped to handle changes in component behavior better.
 As the project is open-source and has a community, we would like to get it involved from the very start.
 The purpose of this post is twofold:
 
-- To serve as a resoure of brainstorming and of forming ideas for improvements, and
-- to put incoming improvements implementations into the appropriate context.
+- To serve as a resource of brainstorming and of forming ideas for improvements, and
+- to put incoming implementation of improvements into the appropriate context.
 
 
 ## Introduction
@@ -30,18 +30,18 @@ Here are some examples:
 
 - Configuration preference changes - instead of putting everything into one file, prefer distributing the configuration into a directory, for example prefer `sshd_config.d` directory over the `sshd_config` file.
 - A configuration option is renamed, e.g. from a `whitelist` to `allowlist`.
-- A feature disappears, and alternative approach is needed - consider the case of OpenSSH losing capabilities of the `SetIdleTimeout 0` option to drop inactive sessions.
+- A feature disappears, and an alternative approach is needed - consider the case of OpenSSH losing capabilities of the `SetIdleTimeout 0` option to drop inactive sessions.
 
 
 ## New Approach Needed
 
-If we think in a very simple way, we clearly need to design smart procedures or workflows that recact to changes, so no major brain power is needed to make the right decisions.
+If we think in a very simple way, we clearly need to design smart procedures or workflows that react to changes, so no major brain power is needed to make the right decisions.
 However, in order to be able to come with workflows that introduce an added value, the project needs to gain some extra capabilities.
 
 Our team has come up with these ideas so far:
 
-- Lower the pressue on rules - enable coverage of a security requirement by more than one rule.
-- Be able to split a rule into such set of rules easily.
+- Lower the pressure on rules - enable coverage of a security requirement by more than one rule.
+- Be able to split a rule into such a set of rules easily.
 - Enhance the declarative aspect of the project.
 - Introduce a component-centric view to the project.
 - Facilitate extension of a rule's scope.
@@ -56,8 +56,8 @@ Let's take a look how those ideas could align to the subject of component change
 In practice, we may not know at build-time what exact version of a component will be scanned, and we may address this uncertainty by having multiple rules prepared to handle this uncertainty.
 When it comes to the actual scanning, this collection of rules has to make sure that the evaluation will be carried out correctly, regardless of what component version is present on the system.
 
-This could be achieved by set of rules with disjoint applicability, so at the end, at most one rule is active.
-In this context, the recently-introduced CPE Applicability Language functionality can be helpful, as it enables content authors to specify that the rule is applicable only when certain conditions s.a. package version are met.
+This could be achieved by a set of rules with disjoint applicability, so at the end, at most one rule is active.
+In this context, the recently-introduced CPE Applicability Language functionality can be helpful, as it enables content authors to specify that the rule is applicable only when certain conditions s.a. packages versions are met.
 
 
 ### Support of rule splitting 
@@ -81,7 +81,7 @@ Macros can also help to reduce copy-pasting, but let's face it - the manual work
 ### Go Declarative
 
 Some areas of the project are already declarative, but to have more is better.
-Declarative way of doing things allows for introduction of more levels of abstraction, and when something changes, it is much more likely that a change will stay contained in one of such abstraction levels.
+Declarative way of doing things allows for the introduction of more levels of abstraction, and when something changes, it is much more likely that a change will stay contained in one of such abstraction levels.
 
 For example, we already have an enhanced declarative part in the form of [control files](https://github.com/ComplianceAsCode/content/tree/master/controls).
 Thanks to that, we don't have to specify relations of rules to the profile directly, but we can focus on a much easier to grasp relation of a rule to a security control.
@@ -91,15 +91,15 @@ As an additional benefit, the assignment of rules to security controls can be re
 However, this declarative concept can be extended beyond profile compositions.
 We often use constructs s.a. `{{% if product in ("rhel8", "rhel9") %}}` instead of a more generic and understandable `{{% if product.prefers_single_file_sshd_configuration %}}` or something analogous.
 
-In other words, we shouldn't miss an opportunity to declare that certain product has a particular property, and every other part of the content should refer to those properties rather than to product names.
+In other words, we shouldn't miss an opportunity to declare that a certain product has a particular property, and every other part of the content should refer to those properties rather than to product names.
 Designing such product properties in a way that is smart, doesn't get in the way and that can be reused in prose, checks and remediations is not trivial.
 
-Can you thing of other ways of bringing declarative principles to the project?
+Can you think of other ways of bringing declarative principles to the project?
 
 
 ###  Be able to track component changes and our reactions to them.
 
-Imagine that a component changes behavior, and you dispatch pull requests that react to that change, and they get merged successfuly.
+Imagine that a component changes behavior, and you dispatch pull requests that react to that change, and they get merged successfully.
 However, later you discover that something is still not right, and you need to check out the reaction to that change.
 What do you do?
 
@@ -108,7 +108,7 @@ However, this information needs to be manually recovered from other changes to t
 That's doable, but it is, to some degree, a detective work.
 
 Wouldn't it be nice to have a capability that would allow us to query a component, and we would get change information from the project using some automation?
-This can be very difficult to achieve exhaustively, but partial and good enough solution may not be so difficult.
+This can be very difficult to achieve exhaustively, but a partial and good enough solution may not be so difficult.
 
 
 ###  Polymorphic rules
@@ -131,5 +131,5 @@ Do you have answers, or even more questions?
 Or do you have worries or objections?
 In any case, reach out to us on [Gitter](https://app.gitter.im/#/room/#Compliance-As-Code-The_content:gitter.im)!
 
-Attempts to implements some improvements outlined here will probably start coming up in some form in course of 2023.
+Attempts to implement some improvements outlined here will probably start coming up in some form in the course of 2023.
 We are early on the cycle, and we are collecting and processing feedback, so our intentions can change is definitely our aim.