6 ms·

> What they ask for is that changes are authorized, tested, approved, and recorded — and pull requests are just one way of doing that. I'm pretty unclear how a

> What they ask for is that changes are authorized, tested, approved, and recorded — and pull requests are just one way of doing that. I'm pretty unclear how approvals are ensured in your system? Authorisation and recording are pretty much out-of-the-box with a version control system, CI can guarantee testing, but how are we demonstrating approval without any evidence of change reviews?

ozim 1mo ago
I think you mistake 'authorized' with 'approved'. Authorized is: Restricted push access. Access to main follows business function: every engineer at Amp can push, and most of Amp is engineers. But the percentage of people with access matters less than being able to explain exactly who has it and why. So like you know exactly who can push the code and let's say random from marketing can't push code because he is not authorized.
- swiftcoder 1mo ago
  No, I understand that. Authorisation is a basic feature of pretty much any hosted version control system. What is less clear here is approvals.
  - yodon 1mo ago
    > What is less clear here is approvals This. My understanding is that SOC2 does require approvals (eg 2nd person reviews/approves the code change). This approach doesn't seem to include that step. Is that not a requirement?
    - gcr 1mo ago
      Amp will probably claim the agent wrote the code and the human approved it
    - plorkyeran 1mo ago
      SOC2 requires basically nothing beyond that you follow the procedures that you say you're going to follow. The relevant text of CC8.1 is: > The entity authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to its infrastructure, data, software, and procedures to meet its objectives. You'll note that this doesn't actually say much of anything. It's very common for companies which are working on SOC 2 compliance to write down that all changes will be reviewed and once you do that you're required to actually follow through and do it, but you don't have to write down that all changes will be reviewed. The point of SOC2 is mostly that if you are vibing slop into production you have to document that fact (or rather, document your lack of change controls that make it possible) and so your customers can be aware of that. Large conservative customers may insist on more rigid processes as a condition of buying from you.
  - ozim 1mo ago
    That is seems is the main point of the article, that you don't need approvals for SOC2.

ozim 1mo ago

I think you mistake 'authorized' with 'approved'. Authorized is: Restricted push access. Access to main follows business function: every engineer at Amp can push, and most of Amp is engineers. But the percentage of people with access matters less than being able to explain exactly who has it and why. So like you know exactly who can push the code and let's say random from marketing can't push code because he is not authorized.

swiftcoder 1mo ago
No, I understand that. Authorisation is a basic feature of pretty much any hosted version control system. What is less clear here is approvals.
- yodon 1mo ago
  > What is less clear here is approvals This. My understanding is that SOC2 does require approvals (eg 2nd person reviews/approves the code change). This approach doesn't seem to include that step. Is that not a requirement?
  - gcr 1mo ago
    Amp will probably claim the agent wrote the code and the human approved it
  - plorkyeran 1mo ago
    SOC2 requires basically nothing beyond that you follow the procedures that you say you're going to follow. The relevant text of CC8.1 is: > The entity authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to its infrastructure, data, software, and procedures to meet its objectives. You'll note that this doesn't actually say much of anything. It's very common for companies which are working on SOC 2 compliance to write down that all changes will be reviewed and once you do that you're required to actually follow through and do it, but you don't have to write down that all changes will be reviewed. The point of SOC2 is mostly that if you are vibing slop into production you have to document that fact (or rather, document your lack of change controls that make it possible) and so your customers can be aware of that. Large conservative customers may insist on more rigid processes as a condition of buying from you.
- ozim 1mo ago
  That is seems is the main point of the article, that you don't need approvals for SOC2.