A process can refer to any set of policies or procedures you follow. It could be algorithmic, or it could simply be documented policies or procedures that have loopholes or flaws. That is, even if the people involved are doing their jobs to the letter, and the technology is doing what it is expected and supposed to, the process can be abused or exploited.
To give a simple example, say a company has a help desk ticketing system that is used to request permission and privileges. It's a common occurrence for additional information to be needed on the ticket, so users can edit tickets they've created, and you can only create a ticket as a logged in user. The process is as follows:
- A user creates a ticket, indicating what codebase or server they need access to.
- Someone from the security team checks that the requesting user is supposed to have those permissions, and adds a comment to the ticket or changes the ticket state to indicate it's approved
- Someone from the IT department processes the ticket, adding the appropriate permissions.
On paper, that might seem superficially secure, as long as people are doing their jobs (e.g. adding the right user to the right permission set) and the technology/ticketing system are secure.
But what if you come in as a user who is supposed to have permission to edit the help documentation, and after that gets approved in step 2, you edit the ticket to instead say you need permission to access source code that you aren't supposed to have access to, or a production database containing sensitive information, etc? The IT department user in step 3 may look at the ticket, look at the approval, and you now have permissions you aren't actually supposed to have.
What you have is a failure of process, because the official/documented policy doesn't take into account the ability to edit tickets. You might fix the policy by not allowing ticket edits after approval, or by requiring the IT user in Step 3 to look at an edit history of the ticket - but as documented and followed, the process is fundamentally insecure.
To explain how that ties into the blog post you linked - technology and automation could clean up the loophole in the procedure itself. Maybe when security approves it, they directly tie the ticket into the repository that you're supposed to have permission to, and it's forwarded to the IT department as a new ticket, or automated entirely. That removes both one of the human factors for error (IT admin misreading a safe and unedited ticket, or selecting the wrong username), and the process loophole (no verification between steps 2 and 3).