fix broken links to ENISA

draft/09-training-education/06-mobile-top-ten.md

@@ -73,9 +73,9 @@ but they can be applied at any time during development.
 The Mobile Top 10 was [first released in 2014][mobile10-2014], [updated in 2016][mobile10-2016]
 with the latest version [released in 2024][mobile10-2023].
 
-The list of mobile application [controls][mobile10controls] were originally published in 2011
-as the '[Smartphone Secure Development Guideline][ssdg-2011]'. This was then revised during 2016
-and [released in February 2017][ssdg-2017] to inform the latest set of mobile application controls.
+The list of mobile application [controls][mobile10controls] were originally published in 2011 by [ENISA][enisa]
+as the 'Smartphone Secure Development Guideline'.
+This was then revised during 2016, released in February 2017, to inform the latest set of mobile application controls.
 
 ----
 
@@ -101,7 +101,5 @@ then [submit an issue][issue0906] or [edit on GitHub][edit0906].
 [mobile10-2023]: https://owasp.org/www-project-mobile-top-10/2023-risks/
 [mobile10controls]: https://owasp.org/www-project-mobile-top-10/#div-controls
 [mobile10repo]: https://github.com/OWASP/www-project-mobile-top-10/blob/master/README.md
-[ssdg-2011]: https://www.enisa.europa.eu/publications/smartphone-secure-development-guidelines/at_download/fullReport
-[ssdg-2017]: https://www.enisa.europa.eu/publications/smartphone-secure-development-guidelines-2016
 
 \newpage

release-process.md

@@ -8,8 +8,8 @@ The pre-release process is semi-automatic, and triggers when the repo is tagged
 To trigger the release this process from within a cloned repo use a tag with an `-RCx` suffix,
 where the number is incremented with each release candidate:
 
-1. tag the release, for example for the first release candidate: `git tag 4.1.4-RC1`
-2. push to the repo, for example: `git push origin 4.1.4-RC1`
+1. tag the release, for example for the first release candidate: `git tag 4.1.6-RC1`
+2. push to the repo, for example: `git push origin 4.1.6-RC1`
 
 The github release workflow will then create the pull-request with the proposed modifications to the release area.
 
@@ -24,8 +24,8 @@ When there are no further changes required then move on to the release process.
 The release process is automatic, and triggers when the repo is tagged with a version number.
 To trigger the release this process from within a cloned repo:
 
-1. tag the release, for example: `git tag 4.1.3`
-2. push to the repo, for example: `git push origin 4.1.3`
+1. tag the release, for example: `git tag 4.1.6`
+2. push to the repo, for example: `git push origin 4.1.6`
 
 The github release workflow then creates the pull request
 with modifications to the release area promoted from the draft area.