# SAM

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/sam

## Quick definition

SAM helps track who made changes in a software project and links those changes to a user account. It is used in CI/CD pipelines to ensure every code update is traceable. This is important for security and for understanding who caused a problem. Without SAM, it can be hard to know who changed what in a project.

## Simple meaning

Imagine you work in a library where many people can add or remove books. If there is no system to know who added or removed a book, it becomes very hard to find out who made a mistake or who suggested a great new book. SAM is like a system that gives each librarian a unique ID card, and every time they add or remove a book, the system notes down their ID. This way, you can always check who did what.

In the world of software, many developers work on the same code. They use a tool called a version control system, like Git, to keep track of changes. SAM takes this a step further. It does not just track that a change was made; it maps that change directly to a specific user account in the company's system. For example, if a developer named Alice pushes some new code, SAM makes sure that the change is linked to Alice’s official account. This is helpful because sometimes developers might use different computers or different names locally, but SAM standardizes the connection.

Think of it like a school where every student has a uniform with their name on it. Even if two students look alike, you can always tell who is who by the name tag. SAM is that name tag for code changes. It is especially important in CI/CD pipelines, which are automated systems that test and deploy code. If a bug causes a website to crash, SAM helps the team quickly find who made the change that broke it, so they can fix it faster. This makes the whole software process safer and more reliable, which is why many IT certifications cover it.

## Technical definition

SAM, or Source Account Mapping, is a mechanism used in CI/CD (Continuous Integration and Continuous Deployment) pipelines and monitoring systems to correlate source code commits with authenticated user identities from an organization’s directory services, such as Active Directory or LDAP. In a typical software development environment, developers commit code to a version control system like Git using a local or configured username and email address. However, these credentials can be arbitrary or spoofed, creating a security gap. SAM solves this by integrating with authentication protocols like OAuth, SAML, or Kerberos to verify the identity of the user initiating the commit, then stores that verified identity alongside the commit metadata.

The process begins when a developer pushes code to a remote repository, such as GitHub, GitLab, or Bitbucket. The CI/CD server, which is often configured as a webhook receiver, intercepts the push event. SAM then validates the user’s session or token against the identity provider. If the token is valid, the mapping is recorded as an immutable log entry. This log entry typically includes fields like commit hash, timestamp, verified username, and the source IP address. Many monitoring tools, such as Prometheus or Splunk, can ingest this log data to produce audit trails or alerts. For example, if a build fails due to a malicious code injection, the operations team can query the SAM logs to see exactly which authenticated user pushed that commit, even if the commit itself had a fake or mismatched email.

Standards involved include OAuth 2.0 for token-based authentication, SAML 2.0 for enterprise single sign-on, and X.509 certificates for machine-level mapping. In on-premises environments, SAM may use Windows Integrated Authentication via Kerberos to directly pull the user’s domain account. The mapping is often stored in a relational database or a blockchain-like ledger for tamper-proof auditing. SAM is not a single product but a design pattern that can be implemented in Jenkins, GitLab CI, or custom scripts. It is also related to the concept of non-repudiation in information security, where a user cannot deny having performed an action. In exam contexts, SAM is closely tied to chapters on access control, continuous monitoring, and secure DevOps practices, and is often a question topic in the CompTIA Security+, CISSP, and AWS Certified DevOps Engineer exams.

## Real-life example

Think about a neighborhood watch program. Every resident has a key to the community gate, and there is a logbook at the gatehouse. When someone enters with their key, they are supposed to write down their name and the time. But sometimes residents forget, or they write a fake name for fun. This makes it hard to know who actually came in at 2 AM.

Now imagine the neighborhood installs a smart gate system. Instead of using a regular key, each resident gets a personal electronic key fob that is linked to their official ID card. When the fob is used to open the gate, the system automatically records the resident’s verified name, their badge number, and the exact time. No one can write a fake name because the system reads the fob directly. This is exactly what SAM does for code changes.

In a software company, developers are like residents, and the code repository is the neighborhood gate. The CI/CD pipeline is the gatehouse. Without SAM, a developer could push code under a false name or a generic account, making it impossible to trace who really made a change. With SAM, the CI/CD system checks the developer’s login session or API token against the company’s central directory, just like the smart gate checks the key fob. The log becomes trustworthy, and if a problem happens, the team knows exactly which developer to talk to. This simple upgrade from an honor system to an automated verification system saves hours of investigation time and prevents security breaches.

## Why it matters

In any IT environment that involves multiple developers working on the same codebase, accountability is critical. SAM matters because it closes a security vulnerability that exists in many version control systems: the ability to spoof a commit author. Without SAM, a malicious insider could intentionally commit code under a colleague’s name, causing confusion or framing someone else for an error. During a security incident, the first step is often to identify who made the last change that caused the vulnerability. If the commit metadata is unverified, the investigation can lead to dead ends or wrong accusations.

For monitoring, SAM provides an accurate source of data for audit trails required by compliance frameworks like SOC 2, PCI DSS, or HIPAA. Auditors often demand proof that changes to production systems are traceable to specific individuals with authorized access. SAM generates this proof automatically, reducing the manual work of reconciling logs. In CI/CD, SAM can also be used to implement access controls. For example, only commits from verified senior developers might be allowed to trigger a deployment to production. This prevents junior or unauthorized developers from accidentally pushing unstable code to live servers.

From a practical standpoint, implementing SAM is relatively inexpensive but yields high returns in trust and efficiency. It reduces the time spent in post-mortem meetings trying to determine who made a change. It also empowers teams to use blame-based debugging without fear of false accusations. In a world where software supply chain attacks are rising, SAM is a low-cost way to ensure that every piece of code has a verified owner.

## Why it matters in exams

SAM appears in several major IT certification exams because it touches on core concepts of access control, authentication, and secure development practices. In the CompTIA Security+ (SY0-601) exam, SAM is relevant to the domain on Threats, Attacks, and Vulnerabilities, specifically under the topic of identity and access management. Questions may ask how to prevent spoofing of commit authorship or how to implement non-repudiation in a DevOps environment. The exam objectives also cover the principle of least privilege and accountability, both of which SAM supports.

For the CISSP exam, SAM relates to the Identity and Access Management (IAM) domain and the Software Development Security domain. CISSP candidates should understand how SAM fits into the software development lifecycle as a control for ensuring code integrity. Questions might present a scenario where a company discovers unauthorized code in production and ask the best method to trace the origin. The correct answer would involve implementing a source account mapping solution to link commits to authenticated users.

The AWS Certified DevOps Engineer exam includes SAM as part of the Continuous Integration and Continuous Delivery section. AWS services like CodeCommit and CodePipeline do not have native SAM, but candidates are expected to know how to integrate third-party tools or custom scripts to achieve similar mapping. Exam questions often ask how to enforce that only users with valid IAM roles can push code to a repository, which is a related concept.

In the GitLab Certified Associate exam, SAM is more directly tested because GitLab has features like push rules that verify commit authors against GitLab user accounts. Learners should know how to enable these rules and understand what happens when a commit does not match a verified user. The exam might include a scenario where a pipeline fails because a commit was pushed by an unverified user, and the candidate must choose the correct configuration fix.

Overall, exam questions on SAM rarely ask for the acronym definition directly. Instead, they present a problem involving commit traceability, and the correct answer involves implementing a mapping mechanism. Learners should focus on understanding the underlying problem SAM solves: unverified commit authorship. They should also be comfortable with exam traps where a fake solution like "enforcing strong passwords on the local Git client" is offered as a distractor.

## How it appears in exam questions

Exam questions about SAM typically fall into three patterns: scenario-based troubleshooting, configuration best practices, and security incident analysis. In scenario-based questions, the exam describes a company where several developers have pushed code that caused a production outage. The lead developer reviews the Git log and sees that the author field shows names of employees who were on vacation. The question asks what should be implemented to prevent this from happening again. The correct answer is to implement source account mapping that verifies each commit against an authentication directory. A distractor might be "require two-factor authentication for the Git server," which is good for login but does not solve the commit spoofing problem.

Configuration-type questions often appear in the context of GitLab or Jenkins. For example, the question may give a snippet of a.gitlab-ci.yml file and ask what additional step is needed to map commits to authenticated users. The answer might be to configure a push rule that rejects commits if the author email does not match a verified GitLab user email. Another common configuration question involves setting up a Jenkins webhook with an authentication token. The learner must understand that the token alone does not provide SAM; it only gives access to the repository. True SAM requires an additional step to extract the user identity from the token.

Troubleshooting questions present a log showing a failed build with the error "commit author mismatch." The candidate must identify that the local Git configuration was set with a name that does not match the user's directory account. The solution is to update the local Git config to use the correct email or to enable commit signing. In some cases, the question may mention that SAM is working, but the pipeline is still failing because the commit was made by a service account instead of a human developer. The candidate needs to recognize that service accounts should be allowed but only if they are also mapped in the SAM system.

Finally, multiple-choice questions may ask which principle is best supported by SAM. Options might include confidentiality, integrity, availability, and non-repudiation. The correct answer is non-repudiation, because SAM prevents a user from denying they made a commit. These questions are designed to test both theoretical knowledge and practical application, so learners should practice identifying the core function of SAM in different contexts.

## Example scenario

A team of five developers at a retail company is working on an e-commerce website. They use Git for version control and Jenkins for CI/CD. One Friday afternoon, a developer named Maria pushes a change to the payment processing module. The change passes all automated tests and is deployed to production. Over the weekend, customers report that their credit cards are being charged twice. The development team starts an emergency investigation.

When they check the Git log, they see that the last commit to the payment module was authored by "John," but John was on a company retreat and did not have his laptop. The team is confused. Did someone else push code using John's name? They look at the timestamps in Jenkins and see that the build was triggered by a webhook from Git. But Jenkins logs only show the IP address of the Git server, not the actual user who pushed the commit. Without SAM, the team has no reliable way to know who made the change.

After days of manual log analysis, they discover that a new developer accidentally used a shared laptop where the Git user was set to John’s name. The fix is simple: configure the CI/CD pipeline to include a SAM step that checks each commit against the company’s Active Directory. Whenever a commit is pushed, the pipeline calls an API to verify the push token against the user’s session. If the author name in the commit does not match the verified user, the pipeline rejects the build and sends an alert.

After implementing SAM, the team now has a clear record: every commit in Jenkins shows the user ID from Active Directory, not just the text from the Git config. The next time a bug appears, the team can instantly identify the responsible developer and fix the issue without blame games. This scenario is a classic example of why SAM is a cornerstone of secure CI/CD practices.

## Common mistakes

- **Mistake:** Thinking SAM is the same as Git author verification
  - Why it is wrong: Git only records whatever name and email the developer configures locally. It does not verify if that information is real. SAM adds a separate authentication step to confirm the user's identity.
  - Fix: Understand that Git author is just text. SAM is the process of comparing that text against a trusted directory service.
- **Mistake:** Believing SAM is only useful for large enterprises
  - Why it is wrong: Even a small team of two developers can benefit from SAM. Without it, a malicious or careless developer could blame the other. SAM provides accountability at any team size.
  - Fix: Implement a basic SAM check even for small projects using tools like Git hooks or CI pipeline scripts.
- **Mistake:** Confusing SAM with commit signing using GPG
  - Why it is wrong: GPG signing proves the commit was made by a specific private key, but it does not map the key to a corporate user account. SAM is about mapping to a directory identity, not just cryptographic proof.
  - Fix: Use both GPG signing for integrity and SAM for identity mapping in a corporate environment.
- **Mistake:** Assuming SAM is automatically enabled in all CI/CD tools
  - Why it is wrong: Most CI/CD platforms only pass through the commit metadata as provided. They do not verify the user against an external identity provider unless explicitly configured.
  - Fix: Read the documentation of your CI/CD tool to find the specific plugin or setting that enables user identity verification.
- **Mistake:** Using the local Git username as the only source for accountability
  - Why it is wrong: A developer can easily change their local Git configuration to impersonate someone else. This makes the log unreliable for auditing.
  - Fix: Always override or supplement local Git metadata with server-side verification as part of the pipeline.

## Exam trap

{"trap":"An exam question states that a company has implemented SAM by requiring developers to use a specific Git username. This is presented as the correct solution to accountability.","why_learners_choose_it":"Learners see the words 'specific username' and think that standardization solves the problem. They do not realize that a username can still be spoofed if there is no verification step.","how_to_avoid_it":"Remember that SAM requires authentication, not just a naming convention. The correct answer should involve a system that checks the user's credentials from a trusted source like LDAP or an SSO provider."}

## Commonly confused with

- **SAM vs Git author field:** The Git author field is a simple text string set in the local repository configuration. It can be changed by anyone at any time. SAM is a process that verifies the author's identity against an external authentication system before accepting the commit. (Example: If a developer types 'git config user.name Superman', the Git author field shows Superman. SAM would reject that if the developer's real login does not match.)
- **SAM vs GPG commit signing:** GPG signing provides cryptographic proof that the commit was made by someone with access to a specific private key. SAM goes further by linking that key or the commit to a corporate directory identity. GPG is about integrity; SAM is about identity and accountability. (Example: A signed commit proves it came from Alice's key, but if Alice shares her key with Bob, you cannot tell who actually made the commit. SAM would still require Bob to authenticate as himself.)
- **SAM vs IAM roles in AWS:** IAM roles control who can perform actions on AWS resources, such as pushing to a CodeCommit repository. SAM focuses specifically on mapping the commit author to a user identity within the commit metadata itself. IAM is about access control; SAM is about attribution. (Example: IAM ensures only developers in the 'dev-team' group can push code. SAM ensures that when John pushes code, the commit is recorded as being from John, not from a shared service account.)
- **SAM vs audit log:** An audit log records events like who accessed a system or when a change was made. SAM generates a specific type of audit log entry that links a commit hash to a verified user. The audit log is the output; SAM is the process that creates trustworthy input for the log. (Example: Without SAM, an audit log might show a commit from 'unknown'. With SAM, the audit log shows the actual user's name from the company directory.)

## Step-by-step breakdown

1. **Developer commits code to local repository** — The developer writes code and commits it using Git. The commit is labeled with a local author name and email, which the developer can set to anything. This is the raw data that needs verification.
2. **Developer pushes commit to remote repository** — The commit is sent to a remote server like GitHub or GitLab. The push is authenticated using an access token or SSH key, which identifies the person making the push at the transport layer.
3. **Remote repository triggers webhook to CI/CD server** — The remote repository sends a payload to the CI/CD server (e.g., Jenkins) containing the commit details, including the author field from the local config. At this point, the author field is still unverified.
4. **CI/CD server extracts the push user credentials** — The CI/CD server reads the authentication token from the webhook payload or from the push event. This token is linked to the user who pushed the code, not necessarily the commit author.
5. **SAM component verifies the push user against directory service** — The SAM process sends the token to an identity provider (like Active Directory or Okta) to get the verified username. It compares this to the commit author field. If they match, the commit is accepted. If not, the build is flagged or rejected.
6. **Mapping is logged in an immutable store** — The verified identity and commit hash are stored together in a secure log or database. This log becomes the single source of truth for audit and incident response. It cannot be altered by any developer.
7. **CI/CD pipeline continues or is halted** — If the SAM check passes, the pipeline proceeds with building, testing, and deploying the code. If it fails, an alert is sent to the security team, and the pipeline is paused until the identity mismatch is resolved.

## Practical mini-lesson

SAM is not a tool you can buy off the shelf. It is a practice that you must design into your CI/CD pipeline. The most common way to implement SAM is by using a server-side Git hook or a CI job that runs before the build. Let us look at how a professional would set this up in a real environment.

First, identify an identity provider that your company already uses, such as Active Directory, Azure AD, or Google Workspace. Your CI/CD server must be able to authenticate against this provider. For example, in Jenkins, you can install the Active Directory plugin and configure it to use LDAP. When a user logs into Jenkins, Jenkins knows their real identity. However, the tricky part is that the push to Git happens outside of Jenkins. The user pushes to GitHub, and then GitHub triggers Jenkins via webhook. At that point, Jenkins only knows the webhook payload, not the original user's session.

To solve this, many teams use a commit status API approach. When a user pushes to GitHub, the GitHub webhook sends the commit information. Jenkins then starts a pipeline job. The first step of the job is to call the GitHub API to check who pushed the commit. The GitHub API returns the pusher’s username from the authentication token used in the push. Jenkins then compares that username to the commit author. If they match, the job proceeds. If not, the job fails with a message like "Commit author does not match pusher identity."

What can go wrong? A common issue is when a developer uses a personal access token belonging to a service account. The push is attributed to the service account, not the developer. In that case, the SAM check would fail because the developer's name in the commit does not match the service account. The fix is to require each developer to use their own personal access token. Another issue is timeouts, if the identity provider is slow, the SAM step can delay the whole pipeline. Professionals mitigate this by caching recent authentications or using an asynchronous validation approach.

implementing SAM requires coordinating between the version control system, the CI/CD server, and the identity provider. It is worth the effort because it generates audit data that is admissible in compliance audits and legally defensible. For a production system, always include SAM as a mandatory step before compilation or deployment.

## Memory tip

SAM = Source Account Mapping, think 'Sign And Match' to remember that SAM signs the commit with a verified identity after matching it to an account.

## FAQ

**Does SAM require special hardware?**

No, SAM is implemented through software. You only need a CI/CD server, a version control system, and an identity provider like Active Directory or LDAP.

**Can SAM be bypassed by a developer?**

If SAM is enforced server-side, developers cannot bypass it. They must push commits through the verified pipeline. Local changes that skip the pipeline will not be deployed.

**Is SAM the same as code review?**

No, code review is about checking the quality of code. SAM is about verifying who wrote the code. They are complementary but different processes.

**What happens if the identity provider is down?**

Most SAM implementations fail closed, meaning the pipeline stops. Some setups allow a grace period or use cached credentials, but this is a risk for compliance.

**Do I need SAM if I use GitLab's built-in user verification?**

GitLab's push rules can verify that the commit author matches a GitLab user. This is a form of SAM. You still need it because GitLab's default behavior does not enforce this check.

**Is SAM relevant for solo developers?**

For a solo developer, SAM is less critical because there is no risk of impersonation. However, it is good practice to set it up if you plan to grow your team or need audit trails.

## Summary

SAM, or Source Account Mapping, is a vital concept in modern CI/CD and monitoring that ensures every code change is linked to a verified user identity. Without SAM, a team cannot trust the authorship of commits because Git allows anyone to set any name. This poses serious security and accountability risks, especially in environments that handle sensitive data or must comply with regulations like HIPAA or PCI DSS.

In practice, SAM is implemented by adding a step in the CI/CD pipeline that checks the identity of the user who pushed the commit against the author field in the commit. This step uses an identity provider to confirm the user's identity, and if there is a mismatch, the pipeline is halted. This simple check prevents impersonation, simplifies incident response, and produces an audit trail that can be used in legal or compliance contexts.

For IT certification learners, SAM is a cross-cutting topic that appears in exams like CompTIA Security+, CISSP, and AWS Certified DevOps Engineer. It is often tested through scenario-based questions that ask how to trace a malicious change back to a specific user. The key takeaway is that SAM is not just a technical feature but a security control that supports the principle of non-repudiation. As software development becomes more collaborative and automated, mastering SAM concepts will help you build and maintain trustworthy systems. Remember the memory tip: 'Sign And Match', always sign the commit to a verified identity by matching it against a trusted directory.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/sam