Student Project Lab: Requesting Security Review and Publication

Overview

Before an application can be published on Student Project Lab, the student or project team must submit a publication request and pass a security review.

The review establishes whether the proposed application meets the technical, security, and operational requirements for public hosting.

Publication requests must identify an exact version of the application.

No application may be published without departmental approval.

1. Before Requesting a Review

Complete the following tasks:

1. Finish the application version you intend to publish.

2. Push all relevant changes to your Git repository.

3. Verify that Docker Compose can build and run the project.

4. Complete the Student Project Lab security checklist.

5. Run applicable automated tests and security scans.

6. Update README.md and DEPLOYMENT.md.

7. Create a release-candidate Git tag.

8. Record the full commit SHA.

For example:

git tag -a v1.0.0-rc.1 -m "Publication candidate"
git push origin v1.0.0-rc.1
git rev-parse v1.0.0-rc.1^{commit}

If the repository is private, confirm that the designated reviewers have access.

2. Submitting a Publication Request

Submit your request through the department-designated Student Project Lab publication request board.

The department will provide the submission link.

The request must include:

Project information

• Project name.

• Student name or team members.

• Course or project affiliation, if applicable.

• Brief description and intended audience.

• Repository URL.

• Requested project subdomain.

Release information

• Release-candidate tag.

• Full Git commit SHA.

• Link to the repository documentation.

• Build and startup instructions.

• Confirmation that the submitted revision runs successfully.

Architecture and operations

• Programming language and framework.

• Required containers and services.

• Database technology, if applicable.

• Persistent storage requirements.

• Required environment variable names.

• External API and network dependencies.

• Estimated resource requirements.

• Initial setup or database migration instructions.

Do not include actual passwords or secret values.

Security information

• Confirmation that the security checklist has been completed.

• Summary of automated testing and scans performed.

• Known vulnerabilities or unresolved issues.

• Authentication and authorization approach.

• Description of any stored personal information.

• Disclosure of higher-risk application features.

• Description of any unusual container privileges, networking, or filesystem access.

Demonstration access

If the application requires authentication, explain how reviewers can test it.

Provide temporary demonstration credentials through a department-approved private communication channel, not a public GitHub issue.

3. Review Process

After submission, the request follows this process:

Initial screening: The department checks whether the submission is complete and suitable for the hosting environment.

Technical review: The reviewer verifies that the application can build, start, and operate using the documented deployment configuration.

Security review: The reviewer examines the applicable security requirements, including deployment settings, dependencies, authentication, authorization, and other relevant controls.

Review decision: The reviewer approves the release, requests changes, or rejects the publication request.

Deployment: An authorized department administrator deploys the approved revision.

Publication verification: The deployed application is checked for basic functionality, correct routing, HTTPS, and operational health.

Reviews may involve source-code inspection, automated scanning, application testing, and requests for clarification.

4. Responding to Review Findings

If changes are required, the reviewer will describe the findings and expected corrections.

Students must:

1. Correct the identified problems.

2. Run relevant tests again.

3. Commit and push the corrections.

4. Create a new release-candidate tag.

5. Update the publication request with the new tag and commit SHA.

6. Explain how the findings were addressed.

Example:

git tag -a v1.0.0-rc.2 -m "Security review corrections"
git push origin v1.0.0-rc.2

Do not overwrite or move the original release-candidate tag.

The reviewer will examine the revised version and determine whether additional changes are necessary.

5. Approval and Publication

Once the review is approved, the department records the approved commit and authorizes a production release.

For example:

An authorized department process selects the approved Git commit or immutable build artifact for deployment.

Students do not need production server credentials or direct access to Coolify.

After publication, the department verifies the application and provides its public URL.

6. Updating a Published Application

To publish an updated version:

1. Complete the updated code.

2. Test the changes.

3. Create a new release-candidate tag, such as v1.1.0-rc.1.

4. Submit an update request referencing the existing application.

5. Describe the changes and their security implications.

6. Complete any required review.

7. Wait for the department to deploy the approved release.

The department may use a reduced review process for low-risk changes, but all production updates require authorization.

If the update changes the database schema, the student must document migration requirements and potential rollback limitations.

7. Problems After Publication

Students must report discovered security vulnerabilities, exposed credentials, data loss, or serious application failures promptly through the designated private faculty or administrator contact.

Do not post active credentials, sensitive logs, vulnerability exploit details, or private user information in a public GitHub issue.

The department may temporarily disable the application while a problem is investigated.

Routine code corrections must follow the approved update procedure.

8. Publication Request Template

Copy this information into the designated publication request form if a structured form is not yet available.

Project

Project name:

Student(s):

Course or affiliation:

Project description:

Repository URL:

Requested subdomain:

Release

Release candidate tag:

Full commit SHA:

README URL:

Deployment instructions URL:

Tests completed and results:

Deployment

Framework/technology stack:

Required containers:

Application's internal HTTP port:

Database and storage requirements:

Environment variable names:

External service dependencies:

Estimated resource requirements:

Special initialization or migration instructions:

Security

Authentication and authorization approach:

Type of data stored:

Higher-risk features:

Security scans performed and results:

Known vulnerabilities or limitations:

Special permissions or infrastructure requirements:

Student Certification

• The submitted release represents the exact code intended for publication.

• The application runs successfully using the documented configuration.

• I have read and followed the Student Project Lab security requirements.

• I have disclosed known security issues and relevant operational risks.

• I have not committed production credentials or secrets.

• I understand that changes to an approved release require additional authorization.

9. After Your Application Is Published

Once your application is live, you may include its public URL in your portfolio, resume, or project documentation.

Keep the corresponding source-code repository available, subject to any course, research, or intellectual-property restrictions.

Students should monitor project issues and remain available to address significant security or operational problems during the approved hosting period.

Publication on Student Project Lab indicates that a specific version was accepted for hosting. It does not imply that the department endorses every statement, feature, or use of the application.