Configuring Amazon Q Developer code references to catch GPL suggestions before commit

What a code reference tells you

AI coding assistants can suggest code that resembles open source code published under copyleft licenses such as the GPL. Amazon Q Developer's code reference capability addresses this by attaching reference information to a suggestion that resembles open source training data. The two details that matter most for review are the license type and the repository source.

The license type tells a reviewer which policy question applies. A permissive license and a GPL attribution lead to different decisions, and your organization's license policy should state which are acceptable without review and which are not. The repository source tells the reviewer where the resembling code came from, which helps judge how much of the suggestion matches and whether the match is incidental or substantial.

Two behaviors shape everything that follows. Reference logging and review depend on individual developer behavior, and they happen after a suggestion is accepted. A reference that one developer sees and ignores leaves nothing in the pipeline to stop the code from reaching a commit.

Configure the setting at the right level

The code reference setting exists at three levels: the individual IDE, the profile, and the organization. For a team, the goal is to make the organization or profile configuration the source of truth so that compliance does not rest on each developer's local choice. A setting that each engineer can change independently is a preference, not a control.

Make three decisions before rollout. First, decide whether the team permits suggestions that resemble open source code at all, or permits them only with references visible. Second, name an owner for the setting, such as the platform engineering team, and record who may change it and how changes are approved. Third, decide how the IDE-level configuration will be verified, for example through onboarding documentation and periodic spot checks.

Document the chosen configuration as a named control. OWASP's DevSecOps Verification Standard lists Software License Compliance (CODE-006) as its own Code/Build phase item, alongside Software Composition Analysis (CODE-005) and Inline IDE Secure Code Analysis (CODE-007). Treating the assistant's reference feature as one layer, and the license check as another, keeps ownership clear.

What the feature does and does not cover

Code references are a detection aid inside the assistant. They indicate that a suggestion resembles known open source code, and they report the license and repository associated with that resemblance. They are not a license determination, and they do not decide whether your use of the code is acceptable.

The absence of a reference is not evidence that code is original or free of license obligations. A reference-based signal can only describe what the assistant matched. Code a developer writes by hand, or code that arrives through other tools, is outside it. Software Composition Analysis (CODE-005) and license compliance scanning (CODE-006) on dependencies remain separate controls and are not replaced by it.

There is also a traceability gap to design around. A reference seen in the IDE is not automatically tied to the lines that end up in a commit. The reference note in step 2 is how you close that gap, and it depends on developers completing it. That dependence on individual behavior is the main weakness of this approach, and it is why the CI check and a human reviewer matter.

Finally, license policy decisions belong to the people responsible for legal and compliance interpretation. The engineering check should flag and route. It should not be written to decide what a GPL obligation means for your product.

Control layers compared

Each layer catches a different failure and leaves a different record. The table shows where enforcement actually happens.

• Assistant reference display: Shows license type and repository source in the IDE. Depends on the developer to act. Operates after a suggestion is accepted and does not block a commit.
• Pre-commit hook: Checks staged changes and reference notes locally. Stops the commit but can be bypassed on a developer machine.
• Pull request and CI check: Runs for every change as a required status. Produces a record tied to the change and the reviewer's decision.
• Runtime policy enforcement: Applies policy on code provenance while the assistant interaction happens, rather than reviewing it afterward.

Enforcing code provenance at runtime

The steps above make review more reliable, but they remain review. They run after a suggestion has been shown and accepted, and they rely on developers and reviewers doing the right thing. For a regulated enterprise that must show an auditor what its AI was allowed to do and what it did, that is a thin basis.

Trussed enforces policy in the execution path, including for coding assistants. Its code provenance capability covers the origin, licence and security context of code, so policy on those attributes is enforced at runtime, not reviewed after the fact. Decisions are allow, redact or block, applied to individual interactions and tool calls.

Each enforcement decision produces audit-ready evidence, so the record of what was permitted and what was stopped comes from the enforcement point itself and not from developer notes. This sits alongside the native reference feature and the pre-commit and pull request checks described above. It does not replace them.