Apply suggestions from code review

Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>

Author: potiuk

airflow-core/docs/security/releasing_security_patches.rst

@@ -32,7 +32,7 @@ release a ``MINOR`` version, the development continues in the ``main`` branch wh
 bugfixes) cherry-picked to the latest released ``MINOR`` line of Apache Airflow. At the moment, when we
 release a new ``MINOR`` version, we stop releasing ``PATCHLEVEL`` releases for the previous ``MINOR`` version.
 
-For example, once we released ``3.1.0`` version on 25 September 2025 and until do not have ``3.2.0`` release,
+For example, once we released ``3.1.0`` version on 25 September 2025 and until we do not have ``3.2.0`` release,
 the security patches will be cherry-picked and released in ``3.1.*`` versions until we release ``3.2.0``
 version. There will be no ``3.0.*`` versions released after ``3.1.0`` has been released.
 

airflow-core/docs/security/vulnerabilities-in-3rd-party-dependencies.rst

@@ -21,20 +21,20 @@ Vulnerabilities in 3rd party dependencies
 How users should treat 3rd-party dependencies with known CVEs
 -------------------------------------------------------------
 
-Apache Airflow has rather big number of dependencies, and we invest a lot of effort to keep Airflow updated
+Apache Airflow has a rather large number of dependencies, and we invest a lot of effort to keep Airflow updated
 to latest versions of those dependencies. We have automation, that checks for new versions of dependencies,
 and attempts to upgrade and test them automatically, we also have security scans that indicate if we have
 minimum versions of dependencies, that are not vulnerable to known, important, exploitable CVEs. Every
 version of Airflow has a set of constraints - i.e. latest tested versions of dependencies, that
-are passing our tests and that we know allow to install Airflow an it's providers together.
+are passing our tests and that we know allow to install Airflow and it's providers together.
 
 However - due to sometimes complex dependency trees and sometimes conflicting requirements, we are not
 always able to upgrade and test dependencies to the latest versions. Sometimes we can only upgrade to newer
 versions of dependencies in the "development" branch - i.e. for the next "MINOR" version of Airflow,
 and we are not able to backport those upgrades to the latest released "MINOR" version of Airflow.
 
 This means that sometimes we have to keep older versions of dependencies in the latest released "MINOR"
-version of Airflow, even if those versions are vulnerable to some CVEs. Since Airflow is volunteer-driven
+version of Airflow, even if those versions are vulnerable to some CVEs. Since Airflow is a volunteer-driven
 project, we do not provide any guarantees that we will upgrade to dependencies that are CVE-free.
 
 Contrary to a common belief, the presence of a CVE in a 3rd-party dependency does not automatically mean
@@ -64,7 +64,7 @@ Airflow reference container images with updated dependencies, so users are on th
 dependencies if they want to, and test if they work with Airflow. What you can do in case your scans
 show some CVEs that you need to update is described in :ref:`docker-stack:fixing-image-at-release-time`.
 
-The easiest way ti get latest, CVE-free dependencies is to upgrade to the latest released version
+The easiest way to get latest, CVE-free dependencies is to upgrade to the latest released version
 of Airflow and keep doing it frequently as we release, this will make it overall easier for the users
 to handle the upgrade process when they do it incrementally and more often, rather than jump a number
 of versions at once.