Technical Audit
The technical audit is Step 3 of the TQS certification process, the core phase where the TQS Committee verifies TQS specification compliance based on submitted deliverables and project source code. This chapter defines the audit methods, item-specific verification methods, verdict criteria, remediation request procedures, and result notification.
31.4.1. Audit Methods
The TQS technical audit is performed using a combination of automated verification and manual review. By combining both methods, items that can be quantified through tools and items requiring human judgment can both be verified.
31.4.1.1. Automated Verification
Automated verification is the method of checking CI/CD pipeline execution results and automated tool verification results. Automated verification accounts for 60% of the overall audit.
The targets and tools for automated verification are as follows.
| Verification Item | Tool | Criteria | Verification Method |
|---|---|---|---|
| Backend code formatting | Spotless (Google Java Format) | 0 violations | Verify mvn spotless:check execution results |
| Frontend linting | ESLint (Flat Config) | 0 errors | Verify npx eslint . execution results |
| Frontend formatting | Prettier | 0 violations | Verify npx prettier --check . execution results |
| Backend test coverage | JaCoCo | Line 80%, Branch 70% | Verify JaCoCo HTML report figures |
| Frontend test coverage | Vitest coverage | Line 80%, Branch 70% | Verify coverage report figures |
| Frontend performance | Lighthouse | Performance score 90+ | Verify Lighthouse report score |
| Dependency security vulnerabilities | OWASP Dependency-Check | 0 with CVSS 7+ | Verify scan report results |
| CI/CD pipeline | CircleCI | Last 5 builds successful | Verify build history |
Automated verification is performed by the TQS Committee directly running the tools or reviewing the results submitted by the project team. For projects with a functioning CI/CD pipeline, the TQS Committee may directly trigger the pipeline and verify the results.
31.4.1.2. Manual Review
Manual review is the method where TQS Committee auditors directly examine source code and project structure. Manual review accounts for 40% of the overall audit.
The targets of manual review are as follows.
- Code conventions: Naming convention compliance, code readability, comment appropriateness
- Architecture patterns: Feature-based package structure, layer separation, dependency direction
- Security implementation: Spring Security configuration, authentication/authorization logic, SQL parameter binding, input validation
- Test quality: Given-When-Then pattern application, meaningfulness of test cases, boundary value test inclusion
- Project structure: Directory structure standards compliance, configuration file management, environment-specific profile separation
- Frontend design: Component design principles, Composition API usage, state management patterns
Manual review is independently performed by a minimum of 2 auditors. Each auditor prepares a review result for their assigned area, and the final verdict is determined through consensus among auditors.
31.4.1.3. Audit Ratios
The ratio of automated verification to manual review varies by audit type.
| Audit Type | Automated Verification | Manual Review | Notes |
|---|---|---|---|
| Initial Audit | 60% | 40% | All items |
| Renewal Audit | 70% | 30% | Changes + core items |
| Change Audit | Variable | Variable | Determined by scope of change |
The higher ratio of automated verification is because a significant portion of TQS specifications can be quantitatively verified through tools. However, manual review additionally verifies design quality, code intent, and security logic appropriateness that tools cannot capture.
31.4.2. Verification Methods by Audit Item
This section defines the automated verification tools and manual review items for each detailed area of the TQS technical audit.
31.4.2.1. Verification Matrix
| Audit Area | Automated Verification Tool | Manual Review Items |
|---|---|---|
| Code Conventions | Spotless, ESLint, Prettier | Naming convention compliance, code readability, comment appropriateness |
| Testing | JaCoCo, Vitest coverage | Test quality, Given-When-Then pattern, boundary value tests |
| Security | OWASP Dependency-Check | Spring Security configuration, SQL parameter binding, input validation, secret management |
| Performance | Lighthouse | Bundle size optimization, image optimization, code splitting |
| Project Structure | --- | Package structure, directory structure, configuration file management |
| CI/CD | CircleCI build logs | Pipeline step configuration, environment separation, build stability |
| Configuration Management | --- | Branch strategy, commit message format, PR process |
| API Design | SpringDoc (Swagger UI) | RESTful conventions, error response format, date format |
31.4.2.2. Detailed Verification Criteria by Area
Code Conventions
The code conventions area verifies the consistency and readability of source code. Automated verification confirms formatting rule compliance, and manual review confirms naming conventions and code quality.
| Verification Item | Verification Method | Pass Criteria |
|---|---|---|
| Google Java Format application | mvn spotless:check | 0 violations |
| ESLint rules application | npx eslint . | 0 errors, minimize warnings |
| Prettier application | npx prettier --check . | 0 violations |
| Java naming conventions | Manual review | Classes (PascalCase), methods (camelCase), constants (UPPER_SNAKE_CASE) |
| Vue component naming | Manual review | PascalCase file names, multi-word component names |
| TypeScript strict mode | tsconfig.json verification | strict: true configured |
Testing
The testing area verifies the sufficiency and quality of tests. Coverage metrics are evaluated alongside test code writing patterns and meaningfulness.
| Verification Item | Verification Method | Pass Criteria |
|---|---|---|
| Backend line coverage | JaCoCo report | 80% or above |
| Backend branch coverage | JaCoCo report | 70% or above |
| Frontend line coverage | Vitest coverage | 80% or above |
| Frontend branch coverage | Vitest coverage | 70% or above |
| Given-When-Then pattern | Manual review | Applied to all JUnit 5 tests |
| Component tests | Manual review | Tests written for key components |
| Composable tests | Manual review | Tests written for composables containing business logic |
Security
The security area verifies the project's security implementation level. Security items are held to stricter criteria than other areas, and non-compliance with Critical items constitutes an immediate fail.
| Verification Item | Verification Method | Pass Criteria | Severity |
|---|---|---|---|
| TLS 1.2 or above applied | Configuration file verification | Applied | Critical |
| Password BCrypt hash | Manual review | Applied | Critical |
| Spring Security applied | Manual review | Authentication/authorization configured | Critical |
| SQL parameter binding | Manual review | jOOQ binding used, no string concatenation | Critical |
| Secrets in source code | Manual review | 0 hardcoded instances | Critical |
| Bean Validation applied | Manual review | Validation annotations on request DTOs | High |
No v-html usage | Manual review | Not used or DOMPurify applied | High |
| OWASP scan | Report verification | 0 with CVSS 7+ | High |
31.4.3. Verdict Criteria
The technical audit verdict is classified into 3 categories: Pass, Conditional Pass, and Fail. The verdict criteria are determined based on the compliance rate of mandatory items and the compliance status of security Critical items.
31.4.3.1. Verdict Criteria Table
| Verdict | Mandatory Item Compliance Rate | Security Critical | Condition |
|---|---|---|---|
| Pass | 100% | All compliant | All mandatory items are met |
| Conditional Pass | 90% or above, below 100% | All compliant | Non-compliant items to be remediated within 2 weeks |
| Fail | Below 90% | --- | Mandatory item compliance rate below 90% |
| Fail | --- | 1 or more non-compliant | Security Critical item non-compliance |
31.4.3.2. Pass
A pass is the verdict issued when all mandatory items are met. Projects receiving a pass verdict proceed immediately to the certification issuance step (Step 4).
The certification grade is determined at the time of the pass verdict. Grades are classified as Basic, Advanced, or Premier based on the compliance rate of recommended items.
| Grade | Mandatory Items | Recommended Item Compliance Rate |
|---|---|---|
| Basic | 100% compliant | Below 80% |
| Advanced | 100% compliant | 80% or above, below 100% |
| Premier | 100% compliant | 100% |
31.4.3.3. Conditional Pass
A conditional pass is the verdict issued when the mandatory item compliance rate is 90% or above but below 100%. Security Critical items must all be in a compliant state.
The following conditions are imposed with a conditional pass verdict.
- A remediation request document is issued for non-compliant items.
- The remediation deadline is 2 weeks (10 business days) from the verdict date.
- All non-compliant items must be resolved within the remediation deadline.
- A re-verification audit must be completed after remediation.
If remediation is not completed within the deadline, the conditional pass is converted to a fail. The remediation deadline cannot be extended.
31.4.3.4. Fail
A fail is the verdict issued when the mandatory item compliance rate is below 90% or when security Critical items are non-compliant.
Projects receiving a fail verdict must follow the following procedures.
- Review the details of non-compliant items through the audit report.
- Perform remediation work on non-compliant items.
- Restart the process from Step 1 (Pre-Review) after remediation is complete.
- When requesting a re-audit, the remediation details for items identified in the previous audit must be specified.
There is no minimum waiting period between a fail verdict and re-audit. The project team may request a re-audit immediately upon completing remediation.
31.4.4. Remediation Request Procedure
The remediation request procedure begins upon a conditional pass verdict. The remediation request is a systematic process for clearly communicating non-compliant items and verifying remediation completion.
31.4.4.1. Remediation Procedure Flow
The details of each step are as follows.
| Step | Responsible Party | Activity | Duration |
|---|---|---|---|
| Remediation Request Issuance | TQS Committee | Specify non-compliant items, remediation criteria, and deadline | Immediately after verdict |
| Perform Remediation | Project Team | Resolve non-compliant items, code modifications, configuration changes | Up to 2 weeks |
| Remediation Completion Report | Project Team | Submit remediation details and supporting evidence | --- |
| Re-Verification Audit | TQS Committee | Re-verify only remediation items | 3 business days |
| Final Verdict | TQS Committee | Issue pass or fail verdict | Immediate |
31.4.4.2. Remediation Request Contents
The remediation request document includes the following information.
| Item | Content |
|---|---|
| Audit Number | Unique identification number of the audit |
| Project Name and Version | Information about the project under audit |
| Verdict Result | Conditional Pass |
| Non-Compliant Item List | Item number, item name, non-compliance reason, remediation criteria |
| Remediation Deadline | 2 weeks (10 business days) from the verdict date |
| Remediation Completion Report Method | Submission format and submission channel |
| Assigned Auditor | Committee member who will perform the re-verification audit |
31.4.4.3. Re-Verification Audit
The re-verification audit is performed only on items for which remediation was requested. Items judged as compliant in the original audit are not included in the re-verification scope.
The re-verification audit results in only pass or fail. A conditional pass is not issued in the re-verification audit. If all remediation items are met, the verdict is pass; if even one item remains non-compliant, the verdict is fail.
31.4.5. Audit Result Notification
After audit completion, the TQS Committee officially notifies the project team of the audit results.
31.4.5.1. Notification Deadline
Results must be notified within 3 business days from the audit completion date. Notification is delivered to the Project Lead along with an official document (audit report).
31.4.5.2. Audit Report
The audit report is an official document that comprehensively records the audit process and results. The audit report includes the following information.
| Report Item | Content |
|---|---|
| Audit Basic Information | Audit number, project name, version, audit type, audit period |
| Auditor Information | List of committee members who participated in the audit |
| Area-by-Area Audit Results | Results for code conventions, testing, security, performance, structure, and CI/CD areas |
| Item-by-Item Compliance Status | Detailed compliance/non-compliance status of all items |
| Automated Verification Results Summary | Summary of execution results for each tool |
| Manual Review Findings | Auditor code review opinions and improvement recommendations |
| Final Verdict | Pass/Conditional Pass/Fail with rationale |
| Certification Grade (upon pass) | Basic/Advanced/Premier with calculation basis |
31.4.5.3. Objection to Audit Results
The project team may raise an objection to the audit results. Objections must be submitted in writing within 5 business days from the result notification date.
The following must be specified when raising an objection.
- Target item of objection (item number from the audit report)
- Reason for objection (including specific evidence)
- Evidence supporting the project team's claim
The TQS Committee notifies the review results within 5 business days of receiving the objection. If the objection is accepted, the audit result is changed; if it is rejected, the original verdict is maintained. Objections may be raised only once.